This reverts commit 81522a01.

Looks like we're not ready for this yet:
https://lab.llvm.org/buildbot/#/builders/139/builds/41797

Our comparison opcodes always produce a Boolean value and push it on the
stack. However, the result of such a comparison in C is int, so the
later code expects an integer value on the stack.

Work around this problem by casting the boolean value to int in those
cases. This is not ideal for C however. The comparison is usually
wrapped in a IntegerToBool cast anyway.

Differential Revision: https://reviews.llvm.org/D149645

This exposed a miscompile due to incorrect flag preservation in
integer type legalization, which has been fixed in D151472.

-----

This patch is a continuation of D150110. It separates the cases for
ADD and SUB into their own cases so that computeForAddSub can be
directly called and the NSW flag passed. This allows better
optimization when the NSW flag is enabled, and allows fixing up the
TODO that was there previously in SimplifyDemandedBits.

Differential Revision: https://reviews.llvm.org/D150769

This reverts commit e614d566.

Build bot failures:

| FAILED: lib/clang/17/lib/linux/libclang_rt.ubsan_minimal-i386.so
| : && /usr/bin/clang++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -Wno-unused-parameter -O3 -DNDEBUG  -Wl,-z,defs -Wl,-z,nodelete   -m32 -nodefaultlibs -Wl,-z,text -nostdlib++ -shared -Wl,-soname,libclang_rt.ubsan_minimal-i386.so -o lib/clang/17/lib/linux/libclang_rt.ubsan_minimal-i386.so projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o  -lgcc_s  -lc && :
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_type_mismatch_minimal':
| /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:120: undefined reference to `__sanitizer_internal_memcpy'
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_type_mismatch_minimal_abort':
| /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:120: undefined reference to `__sanitizer_internal_memcpy'
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_alignment_assumption_minimal':
| /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:121: undefined reference to `__sanitizer_internal_memcpy'
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_alignment_assumption_minimal_abort':
| /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:121: undefined reference to `__sanitizer_internal_memcpy'
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o: in function `__ubsan_handle_add_overflow_minimal':
| /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:122: undefined reference to `__sanitizer_internal_memcpy'
| /usr/bin/ld: projects/compiler-rt/lib/ubsan_minimal/CMakeFiles/RTUbsan_minimal.i386.dir/ubsan_minimal_handlers.cpp.o:/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:122: more undefined references to `__sanitizer_internal_memcpy' follow

Link: https://lab.llvm.org/buildbot#builders/74/builds/19569

Fixes crash reported in llvm.org/PR62838.

Reviewed By: jryans

Differential Revision: https://reviews.llvm.org/D151326

Save the depth of each InterpFrame and bail out if we're too deep.

Differential Revision: https://reviews.llvm.org/D148614

D135716 introduced -ftrivial-auto-var-init=pattern where supported.
Unfortunately this introduces unwanted memset() for large stack arrays,
as shown by the new tests added for asan and msan (tsan already had this
test).

In general, the problem of compiler-inserted memintrinsic calls
(memset/memcpy/memmove) is not new to compiler-rt, and has been a
problem before.

To avoid introducing unwanted memintrinsic calls, we redefine
memintrinsics as __sanitizer_internal_mem* at the assembly level for
most source files automatically (where sanitizer_common_internal_defs.h
is included).

In few cases, redefining a symbol in this way causes issues for
interceptors, namely the memintrinsic interceptor themselves. For such
source files we have to selectively disable the redefinition.

Other alternatives have been considered, but simply do not work well in
the context of compiler-rt:

	1. Linker --wrap:  this does not work because --wrap only
	   applies to the final link, and would not apply when building
	   sanitizer static libraries.

	2. Changing references to memset() via objcopy:  this may work,
	   but due to the complexities of the build system, introducing
	   such a post-processing step for the right object files (in
	   particular object files defining memset cannot be touched)
	   seems infeasible.

The chosen solution works well (as shown by the tests). Other libraries
have chosen the same solution where nothing else works (see e.g. glibc's
"symbol-hacks.h").

Reviewed By: vitalybuka, dvyukov

Differential Revision: https://reviews.llvm.org/D151152

This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td support.

The patch is quite large.  However, nothing outside the tests is
specific to the first RegularKeyword attribute (__arm_streaming).
The patch should therefore be a one-off, up-front cost.  Other
attributes just need an entry in Attr.td and the usual Sema support.

The approach taken in the patch is that the keywords can be used with
any language version.  If standard attributes were added in language
version Y, the keyword rules for version X<Y are the same as they were
for version Y (to the extent possible).  Any extensions beyond Y are
handled in the same way for both keywords and attributes.  This ensures
that existing C++11 successors like C++17 are not treated differently
from versions that have yet to be defined.

Some notes on the implementation:

* The patch emits errors rather than warnings for diagnostics that
relate to keywords.

* Where possible, the patch drops “attribute” from diagnostics
relating to keywords.

* One exception to the previous point is that warnings about C++
extensions do still mention attributes.  The use there seemed OK
since the diagnostics are noting a change in the production rules.

* If a diagnostic string needs to be different for keywords and
attributes, the patch standardizes on passing the attribute/
name/token followed by 0 for attributes and 1 for keywords.

* Although the patch updates warn_attribute_wrong_decl_type_str,
warn_attribute_wrong_decl_type, and warn_attribute_wrong_decl_type,
only the error forms of these strings are used for keywords.

* I couldn't trigger the warnings in checkUnusedDeclAttributes,
even for existing attributes.  An assert on the warnings caused
no failures in the testsuite.  I think in practice all standard
attributes would be diagnosed before this.

* The patch drops a call to standardAttributesAllowed in
ParseFunctionDeclarator.  This is because MaybeParseCXX11Attributes
checks the same thing itself, where appropriate.

* The new tests are based on c2x-attributes.c and
cxx0x-attributes.cpp.  The C++ test also incorporates a version of
cxx11-base-spec-attributes.cpp.  The FIXMEs are carried across from
the originals.

Differential Revision: https://reviews.llvm.org/D148702

Platform-specific language extensions often want to provide a way of
indicating that certain functions should be called in a different way,
compiled in a different way, or otherwise treated differently from a
“normal” function.  Honoring these indications is often required for
correctness, rather being than an optimization/QoI thing.

If a function declaration has a property P that matters for correctness,
it will be ODR-incompatible with a function that does not have property P.
If a function type has a property P that affects the calling convention,
it will not be two-way compatible with a function type that does not
have property P.  These properties therefore affect language semantics.
That in turn means that they cannot be treated as standard [[]]
attributes.

Until now, many of these properties have been specified using GNU-style
attributes instead.  GNU attributes have traditionally been more lax
than standard attributes, with many of them having semantic meaning.
Examples include calling conventions and the vector_size attribute.

However, there is a big drawback to using GNU attributes for semantic
information: compilers that don't understand the attributes will
(by default) emit a warning rather than an error.  They will go on to
compile the code as though the attributes weren't present, which will
inevitably lead to wrong code in most cases.  For users who live
dangerously and disable the warning, this wrong code could even be
generated silently.

A more robust approach would be to specify the properties using
keywords, which older compilers would then reject.  Some vendor-specific
extensions have already taken this approach.  But traditionally, each
such keyword has been treated as a language extension in its own right.
This has three major drawbacks:

(1) The parsing rules need to be kept up-to-date as the language evolves.

(2) There are often corner cases that similar extensions handle differently.

(3) Each extension requires more custom code than a standard attribute.

The underlying problem for all three is that, unlike for true attributes,
there is no established template that extensions can reuse.  The purpose
of this patch series is to try to provide such a template.

One option would have been to pick an existing keyword and do whatever
that keyword does.  The problem with that is that most keywords only
apply to specific kinds of types, kinds of decls, etc., and so the
parsing rules are (for good reason) not generally applicable to all
types and decls.

Really, the “only” thing wrong with using standard attributes is that
standard attributes cannot affect semantics.  In all other respects
they provide exactly what we need: a well-defined grammar that evolves
with the language, clear rules about what an attribute appertains to,
and so on.

This series therefore adds keyword “attributes” that can appear
exactly where a standard attribute can appear and that appertain
to exactly what a standard attribute would appertain to.  The link is
mechanical and no opt-outs or variations are allowed.  This should
make the keywords predictable for programmers who are already
familiar with standard attributes.

This does mean that these keywords will be accepted for parsing purposes
in many more places than necessary.  Inappropriate uses will then be
diagnosed during semantic analysis.  However, the compiler would need
to reject the keywords in those positions whatever happens, and treating
them as ostensible attributes shouldn't be any worse than the alternative.
In some cases it might even be better.  For example, SME's
__arm_streaming attribute would make conceptual sense as a statement
attribute, so someone who takes a “try-it-and-see” approach might write:

  __arm_streaming { …block-of-code…; }

In fact, we did consider supporting this originally.  The reason for
rejecting it was that it was too difficult to implement, rather than
because it didn't make conceptual sense.

One slight disadvantage of the keyword-based approach is that it isn't
possible to use #pragma clang attribute with the keywords.  Perhaps we
could add support for that in future, if it turns out to be useful.

For want of a better term, I've called the new attributes "regular"
keyword attributes (in the sense that their parsing is regular wrt
standard attributes), as opposed to "custom" keyword attributes that
have their own parsing rules.

This patch adds the Attr.td support for regular keyword attributes.
Adding an attribute with a RegularKeyword spelling causes tablegen
to define the associated tokens and to record that attributes created
with that syntax are regular keyword attributes rather than custom
keyword attributes.

A follow-on patch contains the main Parse and Sema support,
which is enabled automatically by the Attr.td definition.

Other notes:

* The series does not allow regular keyword attributes to take
arguments, but this could be added in future.

* I wondered about trying to use tablegen for
TypePrinter::printAttributedAfter too, but decided against it.
RegularKeyword is really a spelling-level classification rather
than an attribute-level classification, and in general, an attribute
could have both GNU and RegularKeyword spellings.  In contrast,
printAttributedAfter is only given the attribute kind and the type
that results from applying the attribute.  AFAIK, it doesn't have
access to the original attribute spelling.  This means that some
attribute-specific or type-specific knowledge might be needed
to print the attribute in the best way.

* Generating the tokens automatically from Attr.td means that
pseudo's libgrammar does now depend on tablegen.

* The patch uses the SME __arm_streaming attribute as an example
for testing purposes.  The attribute does not do anything at this
stage.  Later SME-specific patches will add proper semantics for it,
and add other SME-related keyword attributes.

Differential Revision: https://reviews.llvm.org/D148700

This patch retroactively classifies all existing keyword attributes
as “custom” keyword attributes, in the sense that the keywords have
their own custom parsing rules.  A follow-on patch will add an
alternative type of keyword.

No functional change intended.

Differential Revision: https://reviews.llvm.org/D148699

Differential Revision: https://reviews.llvm.org/D143334

Differential Revision: https://reviews.llvm.org/D151772

Make sure the invariant expressions are safe to expand. In
particular, we should not speculative a trapping division into
the preheader.

Fixes https://github.com/llvm/llvm-project/issues/62992.

The pass attaches attributes to operations for repro generation
purposes, but never removes them. This is not desirable when the pass
actually succeeds.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D151791

Conservatively return unknown in this degenerate case. This is
hard to hit in practice, because such phis are usually optimized
away before they reach a getObjectSize() call.

Fixes https://github.com/llvm/llvm-project/issues/63013.

They don't change inside the loop.

Seems unnecessary to create a StringRef here just so we can drop the
trailing null bytes. We can do that with the std::string we
create anyway.

Differential Revision: https://reviews.llvm.org/D151300

We should preserve empty lines in output snippets.

Differential Revision: https://reviews.llvm.org/D151301

Instead of creating a CaretLine the size of the SourceLine, just leave
it empty at first, let HighlightRange resize it to fit all the ~, then
resize it to fit the ^. Then we can save ourselves the work to remove
the trailing whitespace again.

Differential Revision: https://reviews.llvm.org/D151286

printWordWrapped() is only called in one place, which passes all
parameters except `Indentation`. So, remove that parameter and use its
default value instead. Also remove the other default parameter values,
since those are unneeded.

They were both only called from one place and did very similar things.
Merge them into one, so we only have to iterate the source line once to
generate the SourceMap.

Differential Revision: https://reviews.llvm.org/D151100

Instead of calling getDecomposedLoc() and then only using the FileID.

Reviewed By: PiotrZSL

Differential Revision: https://reviews.llvm.org/D151431

We don't use the offset returned from SourceManager::getDecomposedLoc
here, so we might as well just use getFileID().

Differential Revision: https://reviews.llvm.org/D151093

Differential Revision: https://reviews.llvm.org/D151078

Don't try to minimize the times we invoke operator<< on the output
stream by keeping a ToPrint string around. Instead, just print the
characters as we iterate over them.

Differential Revision: https://reviews.llvm.org/D151075

Instead of always taking the last op from the worklist, take a random one. For testing/debugging purposes only. This feature can be used to ensure that lowering pipelines work correctly regardless of the order in which ops are processed by the GreedyPatternRewriteDriver.

The randomizer can be enabled by setting a numeric `MLIR_GREEDY_REWRITE_RANDOMIZER_SEED` option.

Note: When enabled, 27 tests are currently failing. Partly because FileCheck tests are looking for exact IR.

Discussion: https://discourse.llvm.org/t/discussion-fuzzing-pattern-application/67911

Differential Revision: https://reviews.llvm.org/D142447

- Added additional tests
- Improved existing tests
- Moved misplaced test files to the correct location

Reviewed By: #libc, philnik

Differential Revision: https://reviews.llvm.org/D151205

Rename parameters and local variables and reorder things a bit to be
closer to their first point of use.

Differential Revision: https://reviews.llvm.org/D150840

Use sint_to_fp instead of select.
Reduce the number of branch instructions and
avoid generating TargetConstantPool for double.

(select cc, 1.0, 0.0) -> (sint_to_fp (zext cc))
https://alive2.llvm.org/ce/z/aoEcd9
https://godbolt.org/z/n543Y9v3e

(select cc, 0.0, 1.0) -> (sint_to_fp (zext (xor cc, 1)))
https://alive2.llvm.org/ce/z/zngvSB

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D151719