D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.

This reverts commit 21e7f734.
I'm unable to find a reason for the memory management issues
that caused the revert, so trying again.

Follow-up to D152959:
--debug-only= requires an asserts build.
The test also needs the x86 target.

We added support for the GNUstep ObjC runtime in 0b626473. In order to check if the target process uses
GNUstep we run an expensive symbol lookup in `CreateInstance()`. This turned out to cause a heavy performance
regression for non-GNUstep inferiors.

This patch puts a cheaper check in front, so that the vast majority of requests should return early. This
should fix the symptom for the moment. The conceptual question remains: Why does `LanguageRuntime::FindPlugin`
invoke `create_callback` for each available runtime unconditionally in every `Process::ModulesDidLoad`?

Reviewed By: jasonmolenda, jingham, bulbazord

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

When a function is declared in the same scope as a class with the same
name then the function hides that class. Currently this is done by a
single check after the main loop in LookupResult::resolveKind, but
this can give the wrong result when we have a using declaration in
multiple namespace scopes in two different ways:

 * When the using declaration is hidden in one namespace but not the
   other we can end up considering only the hidden one when deciding
   if the result is ambiguous, causing an incorrect "not ambiguous"
   result.

 * When two classes with the same name in different namespace scopes
   are both hidden by using declarations this can result in
   incorrectly deciding the result is ambiguous. There's currently a
   comment saying this is expected, but I don't think that's correct.

Solve this by checking each Decl to see if it's hidden by some other
Decl in the same scope. This means we have to delay removing anything
from Decls until after the main loop, in case a Decl is hidden by
another that is removed due to being non-unique.

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

Accidentally left review fixes out of the commit.

* Document the valid states: invalid/unset/pointer
  (Currently both documentation and implementation strongly suggest that
   pointer+invalid is poissible, when it's not)
* Remove unused set() functions, which had different semantics between the
  compressed/uncompressed specialization! (The former allowing escaping the
  tristate into pointer+invalid)
* Make the compressed specialization's internals directly model the tristate,
  rather than pretending pointer + invalid were independent.
* Make members of each version identical where possible, remove repetition
* fix operator= accidentally returning a const reference
* Fix indentation :-)

This was motivated by D157868, in which an experienced clang dev was
confused about the possible states for ExprResult - and I vividly
remember getting very confused about this myself.

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

[DAG] SimplifyDemandedBits - if we're only demanding the msb, a UMIN/UMAX node can be simplified to a AND/OR node respectively.

Alive2: https://alive2.llvm.org/ce/z/qnvmc6

Reviewed By: yassingh

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

This is a follow-up of https://reviews.llvm.org/D157837 in which I
missed a few Flang options in Options.td. This patch simply updates the
remaining options that are already supported by Flang with the relevant
visibility flag:

Fixes:
  * https://lab.llvm.org/buildbot/#/builders/191/builds/22241

[DAG] SimplifyDemandedBits - if we're only demanding the signbit, a SMIN/SMAX node can be simplified to a OR/AND node respectively.

Alive2: https://alive2.llvm.org/ce/z/MehvFB

Fixes #64782

When FIR comes from HLFIR, there will be a fir.declare operation between
the source and the usage of each source variable (and some temporary
allocations). This pass needs to be able to follow these so that it can
still transform loops when HLFIR is used, otherwise it mistakenly
assumes these values are not function arguments.

More work is needed after this patch to fully support HLFIR, because the
generated code tends to use fir.array_coor instead of fir.coordinate_of.

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

This pass is intended to spot cases where we can do better than the
default bufferization and to rewrite those specific cases. Then the
default bufferization (bufferize-hlfir pass) can handle everything else.

The transformation added in this patch rewrites simple element-wise
updates to an array to a do-loop modifying the array in place instead of
creating and assigning an array temporary.

See the RFC at
https://discourse.llvm.org/t/rfc-hlfir-optimized-bufferization-for-elemental-array-updates

This patch gets the improvement to exchange2 but not the improvement to cam4
described in the RFC. I think the cam4 improvement will require better alias
analysis. I aim to follow up to fix this in a later patch. With changes
since the RFC, the pass improves polyhedron channel2 by about 52%.

Depends on: D156805 D157718 D157626

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

This patch updates the lowering of the arm_sme.zero to intrinsics so
that it calculates the correct mask for the tile to zero.

The zero instruction takes an 8-bit mask which specifies which 64-bit
tiles to zero, ZA0.D to ZA7.D correspond to bits 0 to 7. To zero tiles
with element sizes of 8-bit to 32-bit just requires zeroing the right
64-bit tiles.

This is quite easy to calculate, each size has a "base mask" which can
be shifted left by the tile ID to get the mask for that tile.

  base_mask << tile_id

After tile allocation, this will be folded to a constant mask.

Reviewed By: awarzynski

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

Implement basic support for verifying LiveIntervals for PHIs.

Reviewed By: arsenm

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

Reviewed By: alanphipps
Differential Revision: https://reviews.llvm.org/D157608

This commit releases a checker that was developed to a stable level in
the Ericsson-internal fork of Clang Static Analyzer.

Note that the functionality of this checker overlaps with
core.UndefinedBinaryOperatorResult ("UBOR"), but there are several
differences between them:
(1) UBOR is only triggered when the constant folding performed by the
Clang Static Analyzer engine determines that the value of a binary
operator expression is undefined; this checker can report issues where
the operands are not constants.
(2) UBOR has unrelated checks for handling other binary operators, this
checker only examines bitwise shifts.
(3) This checker has a Pedantic flag and by default does not report
expressions (e.g. -2 << 2) that're undefined by the standard but
consistently supported in practice.
(4) UBOR exhibits buggy behavior in code that involves cast expressions,
e.g.
    void foo(unsigned short s) {
      if (s == 2) {
        (void) ((unsigned int) s) << 16;
      }
    }...

During register swapping, the code fragments associated with the
function need to be swapped together (which may be generated during
PGO optimization).

Fix https://github.com/llvm/llvm-project/issues/59730

Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D141931

Fix MSVC "'|': unsafe operation: no value of type '_Ty' promoted to type 'int' can equal the given constant" warning. NFC.

This also re-reverts the commit implementing __builtin_strlen.

I was unable to reproduce the msan issue with an msan-enabled build (for
infrastructure reasons), but I think fixing the target-dependent int
sizes in the implementation of __builtin_fpclassify should work.

Change lowering store iff the data operand is leagalized.  In this way,
llvm can lower only operands first, then lower store instruction later.

Reviewed By: efocht

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

As far as I can tell FeatureLSLFast was originally added to specify that a lsl
of <= 3 was cheap when folded into an addressing operand, so should override
the one-use checks usually intended to make sure we don't perform redundant
work. At a later point it also came to also mean that add x0, x1, x2, lsl N
with N <= 4 was cheap, in that it took a single cycle not multiple cycles that
more complex adds usually take.

This patch splits those two concepts out into separate subtarget features. The
biggest change is the change to AArch64DAGToDAGISel::isWorthFoldingALU, making
ALU operations now produce a ADDWrs if the shift is <= 4.

Otherwise the patch is mostly an NFC as it tries to keep the subtarget features
the same for each cpu. I believe that the Arm OoO CPUs should eventually be
changed to a new subtarget feature that specifies that a shift of 2 or 3 with
any extend should be treated as cheap (just not shifts of 1 or 4).

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

When diverged paths reach an irreducible cycle C, every block inside C gets
marked as a join block. Such a join block J may be contained in a nest of
reducible cycles inside C. When visiting J, we can only expect that the
outermost C is irreducible, which we now correctly assert.

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
    Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]

This reapplies commit f8dadefd, reverted in commit 0e17372b, but
disables RTTI in the test to avoid problems on Windows.

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

Unlucky naming top/bottom for stack bounds, has nothing to do with real
stack top. So top > botton is here, and opposite of
9be88929 assumption.

This is minimal fix in case cherry-picks is needed. Naming fix and
testing (if possible) will be in followup patches.

Introduced in 9be88929.
Can't symply reverted 9be88929 as
it fixes ~10 year old bug, accidentally exposed by
a8bef886.

Test cases in D157680 should be target specific, but miss some limit, add them back to make buildbot pass.

Reviewed By: skan, Hahnfeld

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

Gather instructions could lead to security issues, details please refer to https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html.
This supported options -mno-gather and -mno-scatter, which could avoid generating gather/scatter instructions in backend except using intrinsics or inline asms.

Reviewed By: pengfei

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

Before, we allowed the condition to be simplified to a simple constant
only, otherwise we assumed all successors are live. Now we allow
multiple constants, and mark the default successor as dead accordingly.

Post review feedback on D157364. Don't section the __std_clang_module header by macro, put the headers in alphabetical order and repeat the macro guards. Restore header_information.header_restrictions.

Reviewed By: ldionne, #libc

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

[RISCV] Make the order of tests in riscv-target-features.c eqaul to the extensions listed in the table in RISCVISAInfo.cpp. NFC.

1. Let the order of tests equal to listed in the extension table in RISCVISAInfo.cpp.
2. Separate non-experimental and experimental extensions.
3. Add missing tests for RV32.
4. Add missing tests for some extension.
5. Let line break style be the same.

Fixes https://github.com/clangd/clangd/issues/1568

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

[clang] Support function pointer types with attributes when extracting parameter names for signature help

Fixes https://github.com/clangd/clangd/issues/1729

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

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

As the test case demonstrates, it is possible for a block to be identified as a
join point while not being the header of a reducible cycle. To address this,
when searching for the outermost cycle made divergent by branch outside it, we
first check for an irreducible outermost cycle before checking if the parent is
reducible.

Reviewed By: sameerds

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

This makes "lo" refer to the least significant bits and "hi" refer
to the most significant bits.

Reviewed By: arsenm

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