The support is disabled by default. So far there is instruction
selection, spilling, and frame elimination. It also changes SP
from unswizzled to swizzled as used by flat scratch instructions,
so it cannot be mixed with MUBUF stack access.

At the very least missing:

- GlobalISel;
- Some optimizations in frame elimination in between vector
  and scalar ALU;
- It shall finally allow to always materialize frame index
  as an SGPR, but that is not implemented and frame elimination
  cannot handle it yet;
- Unaligned and/or multidword flat scratch shall work, but it
  is legalized now for MUBUF;
- Operand folding cannot optimize FI like with MUBUF yet;
- It will need scaling the value of the SP/FP in the DWARF
  expression to recover the unswizzled scratch address;

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

This fixes failures in AArch64 buildbots by running the
clang/test/CodeGen/X86/att-inline-asm-prefix.c only when the X86
target is available.

Prepend the module name hash with a fixed string ".__uniq." which helps tools
that consume sampled profiles and attribute it to functions to understand
that this symbol belongs to a unique internal linkage type symbol.

Symbols with suffixes can result from various optimizations in the compiler.
Function Multiversioning, function splitting, parameter constant propogation,
unique internal linkage names.

External tools like sampled profile aggregators combine profiles from multiple
runs of a binary. They use various heuristics with symbols that have suffixes
to try and attribute the profile to the right function instance. For instance
multi-versioned symbols like foo.avx, foo.sse4.2, etc even though different
should be attributed to the same source function if a single function is
versioned, using attribute target_clones (supported in GCC but yet to land in
LLVM). Similarly, functions that are split (split part having a .cold suffix)
could have profiles for both the original and split symbols but would be
aggregated and attributed to the original function that was split.

Unique internal linkage functions however have different source instances and
the aggregator must not put them together but attribute it to the appropriate
function instance. To be sure that we are dealing with a symbol of a unique
internal linkage function, we would like to prepend the hash with a known
string ".__uniq." which these tools can check to understand the suffix type.

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

It's not worth trying to fix these warnings within libunwind, instead
silence them.

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

Since we fixed the definition of `SuitableAlign`[https://reviews.llvm.org/D88659],
`max_align_t` and `__BIGGEST_ALIGNMENT__` are not necessarily the same always.

The original testcase was added here: https://reviews.llvm.org/D59048

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

clang supports option -fsplit-machine-functions and this test checks if the
backtraces are sane when functions are split.

With -fsplit-machine-functions, a function with profiles can get split into 2
parts, the original function containing hot code and a cold part as determined
by the profile info and the cold cutoff threshold.. The cold part gets the
".cold" suffix to disambiguate its symbol from the hot part and can be placed
arbitrarily in the address space.

This test checks if the back-trace looks correct when the cold part is executed.

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

This is a long-delayed follow-up to
5e5b8509.

`TempMDNode` includes a bunch of machinery for RAUW, and should only be
used when necessary. RAUW wasn't being used in any of these cases... it
was just a placeholder for a self-reference.

Where the real node was using `MDNode::getDistinct`, just replace the
temporary argument with `nullptr`.

Where the real node was using `MDNode::get`, the `replaceOperandWith`
call was "promoting" the node to a distinct one implicitly due to
self-reference detection in `MDNode::handleChangedOperand`. The
`TempMDNode` was serving a purpose by delaying uniquing, but it's way
simpler to just call `MDNode::getDistinct` in the first place.

Note that using a self-reference at all in these places is a hold-over
from before `distinct` metadata existed. It was an old trick to create
distinct nodes. It would be intrusive to change, including bitcode
upgrades, etc., and it's harmless so I'm not sure there's much value in
removing it from existing schemas. After this commit it still has a tiny
memory cost (in the extra metadata operand) but no more overhead in
construction.

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

The MemProf compiler-rt support relies on some of the support only built
when COMPILER_RT_BUILD_SANITIZERS was enabled. This showed up in some
initial bot failures, and I addressed those by making the memprof
runtime build also conditional on COMPILER_RT_BUILD_SANITIZERS
(3ed77ecd). However, this resulted in
another inconsistency with how the tests were set up that was hit by
Chromium:
  https://bugs.chromium.org/p/chromium/issues/detail?id=1142191

Undo the original bot fix and address this with a more comprehensive fix
that enables memprof to be built even when COMPILER_RT_BUILD_SANITIZERS
is disabled, by also building the necessary pieces under
COMPILER_RT_BUILD_MEMPROF.

Tested by configuring with a similar command as to what was used in the
failing Chromium configure. I reproduced the Chromium failure, as well
as the original bot failure I tried to fix in
3ed77ecd, with that fix reverted.
Confirmed it now works.

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

Error on -G on AIX for all modes(preprocess, assemble, compile, link).

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

https://alive2.llvm.org/ce/z/XjFPQJ

  define void @src(i64 %value) {
    %t0 = call i64 @llvm.ctpop.i64(i64 %value)
    %gt = icmp ugt i64 %t0, 63
    %lt = icmp ult i64 %t0, 64
    call void @use(i1 %gt, i1 %lt)
    ret void
  }

  define void @tgt(i64 %value) {
    %eq = icmp eq i64 %value, -1
    %ne = icmp ne i64 %value, -1
    call void @use(i1 %eq, i1 %ne)
    ret void
  }

  declare i64 @llvm.ctpop.i64(i64) #1
  declare void @use(i1, i1)

The variable declarations interleaved with logic was really difficult
to read. Instead, simply have two different implementations for _WIN32
and others.

In preparation for Fuchsia support, this CL refactors the memory
mapping functions.

The new functions are as follows:
- for Freeslots and Metadata:
  `void *map(size_t Size, const char *Name) const;`
  `void unmap(void *Ptr, size_t Size) const;`
- for the Pool:
  `void *reservePool(size_t Size);`
  `void commitPool(void *Ptr, size_t Size) const;`
  `void decommitPool(void *Ptr, size_t Size) const;`
  `void unreservePool();`
  Note that those don't need a `Name` parameter as those are fixed per
  function. `{reserve,unreserve}Pool` are not `const` because they will
  modify platform specific class member on Fuchsia.

I added a plethora of `assert()` as the initial code was not enforcing
page alignment for sizes and addresses, which caused problem in the
initial Fuchsia draft. All sizes should now be properly rounded up to
a page.

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

I missed this in https://reviews.llvm.org/D87956.

Reviewed By: void

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

This fixes the bug 47945. It is legal to have a PHI with values
from from the same block, but values must stay the same. In this
case it is illegal to merge different values.

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

Previous attempts:

* 15f6bad6
* 58d0ef2d

The combination results in both link- and build-time dependency which is
the desired behavior.

4dc5573a added `FileEntryRef` in order to
help enable sharing of a `FileManager` between `CompilerInstance`s.

It also added a `StringRef` with the filename on `FileInfo`. This
doubled `sizeof(FileInfo)`, bloating `sizeof(SLocEntry)`, of which we
have one for each (loaded and unloaded) file and macro expansion. This
causes a memory regression in modules builds.

Move the filename down into the `ContentCache`, which is a side data
structure for `FileInfo` that does not impact `sizeof(SLocEntry)`. Once
`FileEntryRef` is used for `ContentCache::OrigEntry` this can go away.

Differential Revision: https://reviews.llvm.org/D89580
Radar-Id: rdar://59908826

Fixes PR47917.

Reviewed By: tstellar

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

This predicate is not specific to cortex-a57 and can be used in other processor
models as well.

Currently, this would not correctly associate a category with the related include if it was top-level (i.e. no slashes in the path). This ensures that we explicitly think about that case.

Reviewed By: gribozavr2

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

ExpandModularHeadersPPCallbacks.cpp:55:15: warning: unused variable 'FileEntry'
    for (auto FileEntry : FilesToRecord)
              ^

https://llvm.discourse.group/t/rfc-standard-memref-cast-ops/1454/15

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

This reverts commit a2ac64dd.

This causing `Assertion Result && "Could not evaluate expression"' failed` at https://bugs.chromium.org/p/chromium/issues/detail?id=1142009

This reverts commit 76c00926.

This is the warning reported in https://reviews.llvm.org/D89599

Ensure we can emit symbol aliases via function attribute
even when function signatures contain incomplete types.

Via bugreport:
https://reviews.llvm.org/D66492#2350947

Reviewed By: erichkeane

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

The tests would previously fail if the `python` executable wasn't found,
because we were missing the mandatory find_package.

Update a few APIs to return non-const references instead of pointers,
and remove associated `const_cast`s and non-null assertions.

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

Extends the tests added in a562dc82 to
cover more vector variants.

Based on discourse discussion, fix the doc string and remove examples with
wrong semantic. Also fix insert_map semantic by adding missing operand for
vector we are inserting into.

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

We do not need to use the implicit cast here. We can instead can rely on
a comparison between two TypeSize objects instead. This algorithm will
work fine with scalable vectors.

Reviewed By: DavidTruby

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

The warning would fire when calling canReplaceGEPIdxWithZero on a GEP
whose source element type is a scalable vector. The size of scalable
vector types is not known, so this optimization cannot be performed.

This patch fixes the issue by:

- bailing out early in this routine if the GEP instruction's source
  element type is a scalable vector.

- making use of getFixedSize -- this removes the dependency on the
  deprecated interface.

Reviewed By: fpetrogalli

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

The warning would fire when calling getGEPCost for analyzing the cost of
a GEP instruction. This would result in the use of the now deprecated
implicit cast of TypeSize to uint64_t through the overloaded operator.

This patch fixes the issue by using getKnownMinSize instead of the
implicit cast. This is possible because the code is already
scalable-vector aware. The semantic behaviour of the code is unchanged
by this patch.

Reviewed By: sdesmalen, fpetrogalli

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

The warning would fire when calling isDereferenceableAndAlignedInLoop
with a scalable load. Calling isDereferenceableAndAlignedInLoop with a
scalable load would result in the use of the now deprecated implicit
cast of TypeSize to uint64_t through the overloaded operator.

This patch fixes this issue by:

- no longer considering vector loads as candidates in
  canVectorizeWithIfConvert. This doesn't make sense in the context of
  identifying scalar loads to vectorize.

- making use of getFixedSize inside isDereferenceableAndAlignedInLoop --
  this removes the dependency on the deprecated interface, and will
  trigger an assertion error if the function is ever called with a
  scalable type.

Reviewed By: sdesmalen

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

Recently there has been renewed interest in improving debug-info for variables
that (partially or otherwise) live on the stack in optimised code.

At the moment instcombine speculates that stack slots are probably going to be
promoted to registers, and prepares the debug-info accordingly. It runs a
function called LowerDbgDeclare which converts dbg.declares to a set of
dbg.values after loads, and before stores and calls. Sometimes the stack
location remains (e.g. for escaped locals). If any dbg.values become undef
where the stack location is still valid we end up unnecessarily reducing
variable location coverage due to our inability to track multiple locations
simultaneously. There is a flag to disable this feature
(-instcombine-lower-dbg-declare=0), which prevents this conversion at the cost
of sometimes providing incorrect location info in the face of DSE, DCE, GVN,
CSE etc.

This has been discussed fairly extensively on PR34136.

The idea of these...