with rigorous integration test

Reviewed By: bixia

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

When the initial relationship between two pairs of values between
similar sections is ambiguous to commutativity, arguments to the
outlined functions can be passed in such that the order is incorrect,
causing miscompilations.  This adds a canonical mapping to each
similarity section, so that we can maintain the relationship of global
value numbering from one section to another.

Added Tests:
Transforms/IROutliner/outlining-commutative-operands-opposite-order.ll
unittests/Analysis/IRSimilarityIdentifierTest.cpp - IRSimilarityCandidate:CanonicalNumbering

Reviewers: jroelofs, jpaquette, yroux

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

The default value of the now deprecated
AllowAllConstructorInitializersOnNextLine was always true
regardless of the value of BasedOnStyle. This patch fixes the typo
in the code that handles the related backward compatibility.

This is another followup to D106591. Even if there is an
instruction that clobbers one of the loads, this doesn't matter if
it happens before the loads. Those instructions aren't affected by
the transform at all.

The gep-references-bb.ll is modified to preserve the spirit of the
test, as the store to @g no longer impacts the transform.

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

We'd added support a while back from breaking the backedge if SCEV can prove the trip count is zero. However, we used the exact trip count which requires *all* exits be analyzeable. I noticed while writing test cases for another patch that this disallows cases where one exit is provably taken paired with another which is unknown. This patch adds the upper bound case.

We could use a symbolic max trip count here instead, but we use an isKnownNonZero filter (presumably for compile time?) for the first-iteration reasoning. I decided this was a more obvious incremental step, and we could go back and untangle the schemes separately.

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

Add missing test coverage uncovered in review of D108006.

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

The last change missed one spot.

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

The Fuchsia build compiles the libc and test code with lots
of warnings enabled, including all the integer conversion warnings.
There was some sloppy type usage here that triggered some of those.

Reviewed By: michaelrj

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

In this mode libc++ headers end up in two directories:
* include/<triple>/c++/v1 for the site config header
* include/c++/v1 for everything else

Also switch from -I to -isystem.

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

IIUC we can't emit `memcmp` between pointers in addressspaces,
doing so will trigger an assertion since the signature of the memcmp
will not match it's arguments (https://bugs.llvm.org/show_bug.cgi?id=48661).

This PR disables the attempt to merge icmps,
when the pointer is in an addressspace.

Reviewed By: #julialang, vtjnash

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

Replace D107203, because __llvm_profile_set_file_object is usually used when the
process doesn't have permission to open/create file. That patch trying to copy
from old profile to new profile contradicts with the usage.

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

According to the standard, if p1 and p2 are both pointers, p1 < p2 and
p2 < p1 can both be false in theory in some cases:

https://eel.is/c++draft/expr.rel#4.3

std::less<void> yields a implementation-defined strict total order over
pointers:

https://eel.is/c++draft/comparisons.general

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

ErrorInfo is a uint64_t and is initialized to all 1s.

Not sure how to test this. Noticed while working on .insn support.

Add a new --order option to choose between available test orders:
the default "smart" order, predictable "lexical" order or "random"
order.  Default to using lexical order and one job in the lit test
suite.

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

This change add an option to llvm-ifs to hide undefined symbols from
its output.

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

LLVM 13.0.0-rc2 shows change of behaviour in enum and interface BraceWrapping (likely before we simply didn't wrap)  but may be related to {D99840}

Logged as https://bugs.llvm.org/show_bug.cgi?id=51640

This change ensure AfterEnum works for

`internal|public|protected|private enum A {`  in the same way as it works for `enum A {` in C++

A similar issue was also observed with `interface` in C#

Reviewed By: krasimir, owenpan

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

Reference types in the return or parameter position did cause the OpenMP
declare variant overload reasoning to give up. We should allow them as
we allow any other type.

This should fix the bug reported on the mailing list:
https://lists.llvm.org/pipermail/openmp-dev/2021-August/004094.html

Reviewed By: ABataev, pdhaliwal

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

Recursion can happen when we see a PHI use the second time or when we
look at a store value operand use again. We already visited the
potential copies and doing so again will just cause endless looping.

Reviewed By: kuter

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

For now we do should not treat byval arguments as local copies performed
on the call edge, though, in general we should. To make that happen we
need to teach various passes, e.g., DSE, about the copy effect of a
byval. That would also allow us to mark functions only accessing byval
arguments as readnone again, atguably their acceses have no effect
outside of the function, like accesses to allocas.

Reviewed By: kuter

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

This seem to be a regression caused by this change:
https://reviews.llvm.org/D60943.
Since we delayed report the error, we would run into some invalid
state in clang and llvm.

Without this fix, clang would assert when passing function into
inline asm's input operand.

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

Changes since aec08e:
* Adjust placement of a closing brace so that the general case actually runs.  Turns out we had *no* coverage of the switch case.  I added one in eae90fdc.
* Drop .llvm.loop.* metadata from the new branch as there is no longer a loop to annotate.

Original commit message:

This special cases an unconditional latch and a conditional branch latch exit to improve codegen and test readability. I am hoping to reuse this function in the runtime unroll code, but without this change, the test diffs are far too complex to assess.

[Codegen][X86] EltsFromConsecutiveLoads(): if only have AVX1, ensure that the "load" is actually foldable (PR51615)

This fixes another reproducer from https://bugs.llvm.org/show_bug.cgi?id=51615
And again, the fix lies not in the code added in D105390

In this case, we completely don't check that the "broadcast-from-mem" we create
can actually fold the load. In this case, it's operand was not a load at all:
```
Combining: t16: v8i32 = vector_shuffle<0,u,u,u,0,u,u,u> t14, undef:v8i32
Creating new node: t29: i32 = undef
RepeatLoad:
t8: i32 = truncate t7
  t7: i64 = extract_vector_elt t5, Constant:i64<0>
    t5: v2i64,ch = load<(load (s128) from %ir.arg)> t0, t2, undef:i64
      t2: i64,ch = CopyFromReg t0, Register:i64 %0
        t1: i64 = Register %0
      t4: i64 = undef
    t3: i64 = Constant<0>
Combining: t15: v8i32 = undef

```

Reviewed By: RKSimon

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

This makes sure, that the text section will have a 2-byte alignment, if
the +c extension is enabled.

Reviewed By: MaskRay, luismarques

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

[RISCV] Add -riscv-v-fixed-length-vector-elen-max to limit the ELEN used for fixed length vectorization.

This adds an ELEN limit for fixed length vectors. This will scalarize
any elements larger than this. It will also disable some fractional
LMULs. For example, if ELEN=32 then mf8 becomes illegal, i32/f32
vectors can't use any fractional LMULs, i16/f16 can only use mf2,
and i8 can use mf2 and mf4.

We may also need something for the scalable vectors, but that has
interactions with the intrinsics and we can't scalarize a scalable
vector.

Longer term this should come from one of the Zve* features

We will try to use GetSystemTimePreciseAsFileTime if possible.
Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/59195b2d7fe26549f70969b0dd487293819f023e/.

Reviewed By: compnerd, #libc, mstorsjo, ldionne

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

This was reduced from a test case which triggered a revert to my recent change to same function.  It turns out we didn't have *any* coverage of the non-branch latch and my patch was blatantly broken.

We don't use double underscores for private header names when they are
in a subdirectory with double underscores already.

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

Only files that actually use min/max are required to do this dance.

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

added new command "process trace save -d <directory>".
-it saves a JSON file as <directory>/trace.json, with the main properties of the trace session.
-it saves binary Intel-pt trace as <directory>/thread_id.trace; each file saves each thread.
-it saves modules to the directory <directory>/modules .
-it only works for live process and it only support Intel-pt right now.

Example:
```
b main
run
process trace start
n
process trace save -d /tmp/mytrace
```
A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To load the trace that was just saved:
```
trace load /tmp/mytrace
thread trace dump instructions
```
You should see the instructions of the trace got printed.

To run a test:
```
cd ~/llvm-sand/build/Release/fbcode-x86_64/toolchain
ninja lldb-dotest
./bin/lldb-dotest -p TestTraceSave
```

Reviewed By: wallace

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

Similar to D97976.
On Linux, most GCC installations are configured with
`--enable-gnu-unique-object` and such GCC emits `@gnu_unique_object` assembly.

The feature is highly controversial and disliked by many folks.
(On glibc DF_1_NODELETE is implicitly enabled and makes dlclose a no-op).

In llvm-project STB_GNU_UNIQUE is assembly only. Clang does not use STB_GNU_UNIQUE.

Use ELFOSABI_GNU to match GNU as behavior and avoid collision with other
OSABI binding values.

Reviewed By: jrtc27

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

The gn build doesn't support xray, so there's no reason to make the xray
headers available. Some CMake checks check if xray includes are
available to determine if xray is usable. Since we don't build the xray
runtime, there are link errors.

Reviewed By: thakis

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

Marking test as unsupported for the same reason as https://reviews.llvm.org/D105204

Reviewed By: abhina.sreeskantharajan

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