This pattern triggers when only the extension bits are truncated.

Reviewed By: dcaballe

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

This was part of the N extension which didn't make it version
1.12 of the privilege specification.

Reviewed By: kito-cheng

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

Reviewed By: #libc, ldionne

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

The module validation script of D144994 validate whether the contents of
an include match its module. An include is the set of files matching the
pattern:
- foo
- foo/*.
- __fwd/foo.h

Several declarations of the stream headers are in the header iosfwd.
This gives issue using the validation script. Adding iosfwd to the set
of matching files gives too many declarations. For example when
validating the fstream header it will pull in declarations of the
istream header. Instead if writing a set of filters the headers are
granularized into smaller headers containing the expected declarations.

Reviewed By: #libc, ldionne

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

In D145589, we made the std::bind placeholders inline constexpr to
satisfy C++17. It turns out that this causes ODR violations since the
shared library provides strong definitions for those placeholders, and
the linker on Windows actually complains about this.

Fortunately, C++17 only encourages implementations to use `inline constexpr`,
it doesn't force them. So instead, we unconditionally define the placeholders
as `extern const`, which avoids the ODR violation and is indistinguishable
from `inline constexpr` for most purposes, since the placeholders are
empty types anyway.

Note that we could also go back to the pre-D145589 state of defining them
as non-inline constexpr variables in C++17, however that is definitely
non-conforming since that means the placeholders have different addresses
in different TUs. This is all a bit pedantic, but all in all I feel that
`extern const` provides the best bang for our buck, and I can't really
find any downsides to that solution.

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

The CHECK-NOT tests were incorrect and impacting the other
tests flag tests negatively, they'd pass as false positives.

Checks if the operation the attirbute resides on is an ModuleOp otherwise it fails.

This commit moves the CFGMST.h file into the include directory. The
implemented algorithm is can be helpful for downstream projects that
want to use the PGO data in a non-standard way.

Reviewed By: gysit

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

Make the phi non-trivial, so SCEV can't see through it.

Legalize soffset of buffer instructions using waterfall loop.

Reviewed By: arsenm

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

This reverts commit 10c17c97. It causes undefined symbol error on chromium windows build. A small repro was uploaded to the code review.

Cleanup how the IsBegin argument is passed and removed unnecessary variable.

With this patch an undefined mask in a shufflevector will be printed as poison.
This change is done to support the new shufflevector semantics
for undefined mask elements.

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

If the condition value of SelectInst may be a poison or undef value,
infer constant range at SelectInst use is incorrect, similar to D143883.
Fixes https://github.com/llvm/llvm-project/issues/62401

Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D149339

This ended up being fixed separately by @rsmith in 1e43349e in a
better/correct way. This patch adds the tests from the original, as
though they are reasonably covered in his patch, explicit versions seem
to have value here.

Additionally, this adds a release note for 1e43349e.

SCEV expressions no longer try to preserve LCSSA form. SCEV
construction will try to look through LCSSA phi nodes. As such,
we also no longer need to limit this special-case fold.

Sometimes a phi can both be trivial and match the
createNodeFromSelectLikePHI() fold. In that case it is generally
more profitable to look through the phi node.

platforms

It seems that on some platforms, the spelling include doesn't work. Make
the test less strict on it.

Reviewed By: fdeazeve

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

Enable -fsanitize=kernel-memory support in Clang.

The x86_64 ABI requires that shadow_origin_ptr_t must be returned via a
register pair, and the s390x ABI requires that it must be returned via
memory pointed to by a hidden parameter. Normally Clang takes care of
the ABI, but the sanitizers run long after it, so unfortunately they
have to duplicate the ABI logic.

Therefore add a special case for SystemZ and manually emit the
s390x-ABI-compliant calling sequences. Since it's only 2 architectures,
do not create a VarArgHelper-like abstraction layer.

The kernel functions are compiled with the "packed-stack" and
"use-soft-float" attributes. For the "packed-stack" functions, it's not
correct for copyRegSaveArea() to copy 160 bytes of shadow and origins,
since the save area is dynamically sized. Things are greatly simplified
by the fact that the vararg "use-soft-float" functions use precisely
56 bytes in order to save the argument registers to where va_arg() can
find them.

Make copyRegSaveArea() copy only 56 bytes in the "use-soft-float" case.
The "packed-stack" && !"use-soft-float" case has no practical uses at
the moment, so leave it for the future.

Add tests.

Reviewed By: eugenis

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

We no longer try to preserve LCSSA form in SCEV representation:
Nowadays, we look through LCSSA PHI nodes directly during SCEV
construction. As such, this separate special case in
getSCEVAtScope() is no longer needed.

/data/llvm-project/mlir/unittests/Analysis/Presburger/UtilsTest.cpp:39:17: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
  auto merge = [this](unsigned i, unsigned j) -> bool { return true; };
                ^~~~
/data/llvm-project/mlir/unittests/Analysis/Presburger/UtilsTest.cpp:52:17: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
  auto merge = [this](unsigned i, unsigned j) -> bool { return true; };
                ^~~~
2 errors generated.

Function pointers can be compared for (in)equality but, but LE, GE, LT,
and GT opcodes should emit an error and abort.

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

For each unused-include/missing-include diagnostic, we provide fix-all
alternative to them.

This patch also adds LSP ChangeAnnotation support.

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

The only way known bits could help identify a known power of two is if
it knows exactly which power of two it is, i.e. if it is a known
constant. But in that case the value should have been simplified to a
constant already. So save some compile time by not calling
computeKnownBits.

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

This should fail when negating __INT_MIN__.

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

The code closely follows the X86 back-end. Applications that make heavy
use of {i64, i64} returns to use two registers strongly benefit from the
reduced number of SelectionDAG fallbacks.

Reviewed By: efriedma

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

/Users/jiefu/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9794:12: error: implicit conversion turns string literal into bool: 'const char[25]' to 'bool' [-Werror,-Wstring-conversion]
    assert("It should not reach here");
    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode13.1/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/include/assert.h:99:25: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __ASSERT_FILE_NAME, __LINE__, #e) : (void)0)
                      ~ ^
1 error generated.

Before checking that template partial specialization is "reachable",
ensure it exists.

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

Reviewed By: shafik, erichkeane

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

We should be checking the current BO here, not the nested one. If
the current BO has nowrap flags (and is UB on poison), then we'll
fetch both operand SCEVs of that BO. We'll check the nested BO
on the next iteration of the do/while loop.

These are not necessarily the same (e.g. or can become add) and
this is what we're switching over in the first place.

/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9793:3: error: variable 'MaddOpc' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized]
  default:
  ^~~~~~~
/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9854:25: note: uninitialized use occurs here
  Madd->setDesc(TII.get(MaddOpc));
                        ^~~~~~~
/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9791:19: note: initialize the variable 'MaddOpc' to silence this warning
  unsigned MaddOpc;
                  ^
                   = 0
/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9793:3: error: variable 'AddOpc' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized]
  default:
  ^~~~~~~
/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9862:46: note: uninitialized use occurs here
      BuildMI(*MF, MIMetadata(Root), TII.get(AddOpc), DstReg)
                                             ^~~~~~
/data/llvm-project/llvm/lib/Target/X86/X86InstrInfo.cpp:9790:18: note: initialize the variable 'AddOpc' to silence this warning
  unsigned AddOpc;
                 ^
                  = 0
2 errors generated.

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

We can create expressions either for constant operand or i1
and/or. The implementation was inverting the latter check.

Added a simple normalize function to divisionrepr and added a simple unittest.
Added a normalizediv call to divisionrepr's removeDuplicateDivs function, which now eliminates divs that are consistent after gcd's normalize

Reviewed By: Groverkss

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