Use GCNHazardRecognizer in postra sched.
Updated tests for the new schedules.

Reviewed By: arsenm

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

Change-Id: Ia86ba2ae168f12fb34b4d8efdab491f84d936cde

This matters for example for the iPhoneSimulator14.0.sdk, which has
a System/Library/Frameworks/UIKit.framework/UIKit that has
LC_BUILD_VERSION with minos of 14.0, so linking against that file
will produce warnings like:

   .../iPhoneSimulator14.0.sdk/System/Library/Frameworks/UIKit.framework/UIKit
   has version 14.0.0, which is newer than target minimum of 12.0.0

when targeting x86_64-apple-ios12.0-simulator. That doens't happen when
linking against UIKit.tbd instead, obviously.

Linking with RC_TRACE_DYLIB_SEARCHING=1 shows that ld64 also searches
the tbd file first, and we already get that right for non-framework
dylibs.

Fixes crbug.com/1249456.

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

Perf script can sometimes give disordered LBR samples like below.

```
          b022500
          32de0044
          3386e1d1
      7f118e05720c
      7f118df2d81f
 0x2a0b9622/0x2a0b9610/P/-/-/1  0x2a0b79ff/0x2a0b9618/P/-/-/2  0x2a0b7a4a/0x2a0b79e8/P/-/-/1  0x2a0b7a33/0x2a0b7a46/P/-/-/1  0x2a0b7a42/0x2a0b7a23/P/-/-/1  0x2a0b7a21/0x2a0b7a37/P/-/-/2  0x2a0b79e6/0x2a0b7a07/P/-/-/1  0x2a0b79d4/0x2a0b79dc/P/-/-/2  0x2a0b7a03/0x2a0b79aa/P/-/-/1  0x2a0b79a8/0x2a0b7a00/P/-/-/234  0x2a0b9613/0x2a0b7930/P/-/-/1  0x2a0b9622/0x2a0b9610/P/-/-/1  0x2a0b79ff/0x2a0b9618/P/-/-/2  0x2a0b7a4a/0x2aWarning:
Processed 10263226 events and lost 1 chunks!

```
 Note that the last LBR record `0x2a0b7a4a/0x2aWarning:` . Currently llvm-profgen does not detect that and as a result an uninitialized branch target value will be used. The uninitialized value can cause creepy instruction ranges created which which in turn will result in a completely wrong profile. An example is like

```

 .... @ _ZN5folly13loadUnalignedIsEET_PKv]:18446744073709551615:18446744073709551615
 1: 18446744073709551615
 !CFGChecksum: 4294967295
 !Attributes: 0
```

Reviewed By: wenlei, wlei

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

Instead of discovering the sink-to block for each operand in the main
loop, the sink-to block can instead be directly queued with the
operands.

This simplifies processing in the main loop and is a NFC change split
off from D104254 as suggested there.

Reviewed By: vitalybuka, emaste

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

This change puts the functionality in commit
c5792aa9 behind a flag that is off by
default.  The original commit is not in Apple's Clang fork (and blocks
are an Apple extension in the first place), and there is one known
issue that needs to be addressed before it can be enabled safely.

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

This reverts commit 76dc8ac3.

Restore the change.  The test had an incorrect negative from testing.
The test is expected to trigger a failure as mentioned in the review
comments.  This corrects the test and should resolve the failure.

Reverted due to build failure on greendragon lldb build.

This reverts commit 9bbc0c1f.

Ignore dbg instructions when collecting stack slot markers. This is
to make sure the coloring is invariant regarding presence of dbg
instructions (even in cases when the dbg instructions might be
badly placed in the input).

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

Having DBG_VALUE instructions referencing a stack slot while being outside
of the LIFETIME_START/LIFETIME_END markers for that stack slot is perhaps
not always ideal (from a debugging perspective), but it might happen during
codegen that we end up with such situations (e.g. positioning of the
DBG_VALUE instruction for a SDDbgOperand::FRAMEIX at ISel is a bit sloppy
in that context).

This patch adds a test case showing that StackColoring currently isn't
debug invariant, and that the position of DBG_VALUE instructions referencing
the stack slots might impact the decision making regarding stack slot reuse.

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

This avoids a -pedantic warning:
warning: ISO C++11 requires at least one argument for the "..." in a variadic macro

See also https://github.com/google/googletest/issues/2271

This reverts commit d0d9e6f0.
Breaks tests, see e.g. https://lab.llvm.org/buildbot/#/builders/188/builds/3326

Follow-up to D109708: Using lib_dirs means this will work with ancient gn binaries.

Change the toolchain definitions to make lib_dirs have the right effect, and
pull out lib_switch of each of the tools while here.

This means we now do pass /LIBPATH: to link.exe, but since we invoke it directly
and not through clang-cl, this doesn't actually require D109624. And since this
is built in to GN, we don't need a config to push the flag to dependents.

This is arguably a bit more idiomatic, and it doesn't require folks to update
their GN binaries. No effective behavior change.

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

This patch implements the following check for THREADPRIVATE construct:
```
A variable that is part of another variable (as an array, structure
element or type parameter inquiry) cannot appear in a threadprivate
directive.
```

Reviewed By: kiranchandramohan

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

Use getValueOrCreateConstantIndexOp introduced by https://reviews.llvm.org/D109601 in multiple places in LinalgOps.cpp.

Reviewed By: nicolasvasilache, springerm

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

When moving a Symbol between Blocks that are in different Sections,
update the symbol tables for each Section. Otherwise
symbol.getBlock().getSection() will not match the contents of
Section::symbols(), which asserts during linking.

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

This introduces a new check, readability-containter-data-pointer.  This
check is meant to catch the cases where the user may be trying to
materialize the data pointer by taking the address of the 0-th member of
a container.  With C++11 or newer, the `data` member should be used for
this.  This provides the following benefits:

- `.data()` is easier to read than `&[0]`
- it avoids an unnecessary re-materialization of the pointer
  * this doesn't matter in the case of optimized code, but in the case
    of unoptimized code, this will be visible
- it avoids a potential invalid memory de-reference caused by the
  indexing when the container is empty (in debug mode, clang will
  normally optimize away the re-materialization in optimized builds).

The small potential behavioural change raises the question of where the
check should belong.  A reasoning of defense in depth applies here, and
this does an unchecked conversion, with the assumption that users can
use the static analyzer to catch cases where we can statically identify
an invalid memory de-reference.  For the cases where the static analysis
is unable to prove the size of the container, UBSan can be used to track
the invalid access.

Special thanks to Aaron Ballmann for the discussion on whether this
check would be useful and where to place it.

This also partially resolves PR26817!

Reviewed By: aaron.ballman

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

SelectionDAG will promote illegal types up to a power of 2 before
splitting down to a legal type. This will create an IntegerType
with a bit width that must be <= MAX_INT_BITS. This places an
effective upper limit on any type of 2^23 so that we don't try
create a 2^24 type.

I considered putting a fatal error somewhere in the path from
TargetLowering::getTypeConversion down to IntegerType::get, but
limiting the type in IR seemed better.

This breaks backwards compatibility with IR that is using a really
large type. I suspect such IR is going to be very rare due to the
the compile time costs such a type likely incurs.

Prevents the ICE in PR51829.

Reviewed By: efriedma, aaron.ballman

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

Followup to https://reviews.llvm.org/D108877 to fix test
failure.

Even though they're implemented via typedefs, we typically
want to treat them like keywords.

We could add hover information / xrefs, but it's very unlikely
to provide any value.

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

We previously had a limitation that TLS variables could not
be exported (and therefore could also not be imported).  This
change removed that limitation.

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

This patch exploits the prefixed load and store instructions utilizing the
refactored load/store implementation introduced in D93370.

Prefixed load and store instructions are emitted whenever we are loading or
storing a value with an offset that fits into a 34-bit signed immediate.
Patterns for the prefixed load and stores are added in this patch, as well as
the implementation that detects when we are loading and storing a value with an
offset that fits in 34-bits.

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

We traverse the entire use list to find the undroppable use.

This was really becoming a direct call during the DAG, so it wasn't as
true to the test purpose.

This addresses the flakyness of (at least) TestMultilineNavigation,
which was failing when the editline history of a concurrently executing
test made leaked in. Using a test-specific home directory ensures the
tests are independent.

Rename methods to clearly signal when they only deal with ASCII,
simplify the parsing of identifier, and use start/continue instead of
head/body for consistency with Unicode terminology.

Currently, Dexter's model for fetching watch values is to build a list of
expressions to watch before running the debugger, then evaluating all of them at
each breakpoint, then finally looking up the values of these expressions at each
line they were expected on. When using dexter on a large project while watching
many different expressions, this is very slow, as Dexter will make a massive
number of calls made to the debugger's API, the vast majority of which are not
being used for anything. This patch fixes this issue by having Dexter only
evaluate expressions at a breakpoint when it will be used by a Dexter command.

Reviewed By: jmorse

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

This updates llvm/utils/sysroot.py to include the "DIA SDK" folder in the
sysroot.

It also updates the build to look for the DIA SDK there if a sysroot is set.

This requires moving LLVM_WINSYSROOT to config-ix.cmake.

For the GN build, I chose to pass a qualified path to diaguids in libs instead
of pushing a config with a `/libpath:` flag. The former requires a GN with
https://gn-review.googlesource.com/c/gn/+/12200, the latter requires D109624.
The former is more like the cmake build, arguably a bit simpler, and it's
easier to check for the wrong GN revision and easier to update GN.

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

`.rgba` vector extension setting in C++ for OpenCL 2021 is now
performed analogously to OpenCL C 3.0. Test case added.

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

Add the makeComposedExtractSliceOp method that creates an ExtractSliceOp and folds chains of ExtractSliceOps by computing the sum of their offsets and by multiplying their strides.

Reviewed By: nicolasvasilache

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

Don't blindly assume they're supported - GCC doesn't support -nostdlib++.

The llvm-project/runtimes directory is supposed to allow building the
runtimes standalone from a newly built Clang, and thus should allow
building with other compilers too.

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

SCEV does not look through non-header PHIs inside the loop. Such phis
can be analyzed by adding separate accesses for each incoming pointer
value.

This results in 2 more loops vectorized in SPEC2000/186.crafty and
avoids regressions when sinking instructions before vectorizing.

Fixes PR50296, PR50288.

Reviewed By: Meinersbur

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

The class of instructions that write to narrow top/bottom lanes only
demand the even or odd elements of the input lanes. Which means that a
pair of VMOVNT; VMOVNB demands no lanes from the original input. This
teaches that to instcombine from the target hooks available through
ARMTTIImpl.

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

Improve parse error message for "at least N operands" op trait.

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

See PR51842.

This fixes an assert firing in the static analyzer, triggered by implicit moves
in blocks in C mode:

This also simplifies the AST a little bit when compiling non C++ code,
as the xvalue implicit casts are not inserted.

We keep and test that the nrvo flag is still being set on the VarDecls,
as that is still a bit beneficial while not really making anything
more complicated.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: NoQ

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