When using `clangd` for cross-compiled projects, it's necessary to use the `--query-driver` flag so that `clangd` can extract the compiler's built-in header paths. However, there's no such flag for `clangd-indexer` so we're unable to build a working static index for these projects.

This patch adds a `--query-driver` flag to `clangd-indexer` for this scenario.

I saw some tests under `clang-tools-extra/clangd/test/` but I think the cross-compilation case is a bit more complex to test. Let me know if you'd like me to look into this further.

Resolves: https://github.com/clangd/clangd/issues/1717

Reviewed By: nridge

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

We were testing for an exact match of zero bits which isn't necessary (we don't care if lower bits are zero) - by inspection as its proven tricky to get a decent test case.

Noticed while clearing up D155472 regressions

Same fix as 8a62d6ba: We need to make sure that the supports-JIT check uses
the same JIT config that will be used in the actual test.

As a side effect, introduce AtomicExpr::getOpAsString() to dump the
AtomicOp string representation.

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

Looks like this test was trying to check if two shifts were combined, but it
was accidentally using the insertelement instead of the splat.

This patch brings a fresh coat of paint to the LLDB website.

This uses the `furo` theme from the suggested theme list, adds some
changes to the css to make it use the full browser window width and
removes the table of contents since the theme generates it automatically.

This patch also rewrites the tables for "GDB to LLDB command map" to
convert them from raw HTML to native inlined code blocks.

To generate the website, make sure you install the theme first with
`pip install furo`, enable sphinx in the cmake invocation` then run
`ninja docs-lldb-html`

Discourse: https://discourse.llvm.org/t/rfc-revamping-lldbs-website

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



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

Use member's type when printing.
This also fixes a bug in warning diagnostic for out of order
initialization with designated initializers so it points to a valid
source location when an anonymous member is being initialized.

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

Reviewed By: aaron.ballman, shafik

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

Implement double precision exp function correctly rounded for all
rounding modes.  Using 4 stages:
- Range reduction: reduce to `exp(x) = 2^hi * 2^mid1 * 2^mid2 * exp(lo)`.
- Use 64 + 64 LUT for 2^mid1 and 2^mid2, and use cubic Taylor polynomial to
approximate `(exp(lo) - 1) / lo` in double precision.  Relative error in this
step is bounded by 1.5 * 2^-63.
- If the rounding test fails, use degree-6 Taylor polynomial to approximate
`exp(lo)` in double-double precision.  Relative error in this step is bounded by
2^-99.
- If the rounding test still fails, use degree-7 Taylor polynomial to compute
`exp(lo)` in ~128-bit precision.

Reviewed By: zimmermann6

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

Only add -ffreestanding flag in full build mode.

Reviewed By: sivachandra

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

even if we know what the result is going to be.
There may be side effects we ought not to ignore,

Fixes #64923

Reviewed By: ChuanqiXu

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

When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.

In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.

Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.

There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.

Fixes #61267

Reviewed By: aaron.ballman, #clang-language-wg

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

This reverts commit ef867d2e.

crash on sanitizer build https://lab.llvm.org/buildbot/#/builders/70/builds/42861/steps/10/logs/stdio

This links to the same information but in a new location.

Missed HasRoundModeOp makes performCombineVMergeAndVOps use wrong operands for
VFCVT_RM instructions.

Reviewed By: luke

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

When SelectiondDAG converts dbg.value intrinsics, it first ensures we have
already generated code for the value operator of the intrinsic. The rationale
being that if we haven't had the need to generate code for this value, it won't
be a debug value that causes the generation.

For example, if the first use the physical register of an argument is a
dbg.value, we are going to hit this code path.  However, this is irrelevant for
entry value expressions: by definition we are not interested in the _current_
value of the physical register, but rather on its value at the start of the
function. To deal with this, this patch changes lowering to handle this case as
early as possible.

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

This is partial revert of cbca9ce9.
That commit removed the code guarding against min/max SPF patterns,
because those are now canonicalized to min/max intrinsics. However,
this is only true for integer min/max, while FP min/max can not
always be canonicalized to an intrinsic. As such, restore a
simplified version of the guard that handles only the FP case.

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

This dependency was introduced by D158638. It seems harmless to add this, as the
Analysis library also does it.

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

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

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

When resolving a frame index with a large offset for v6M execute-only,
we emit a tMOVimm32 pseudo-instruction, which later gets lowered to a
sequence of instructions, all of which are flag-setting. However, a
frame index may be generated for a register spill or reload instruction,
which can be inserted at a point where CPSR is live. This patch inserts
MRS and MSR instructions around the tMOVimm32 to save and restore the
value of CPSR, if CPSR is live at that point.

This may need up to two virtual registers (one to build the immediate
value, one to save CPSR) during frame index lowering, which happens
after register allocation, so we need to ensure two spill slots are
avilable to the register scavenger to ensure it can free up enough
registers for this.

There is no test for the emission (or not) of the MRS/MSR pair, because
it requires a spill or reload to be inserted at a point where CPSR is
live, which requires a large, complex function and is fragile enough
that any optimisation changes will break the test. This bug was easily
found by csmith with -verify-machineinstrs, which I now run regularly on
v6M execute-only (and many other combinations).

Patch by John Brawn and myself.

Reviewed By: stuij

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

Disabled linking by adding -c flag

Reviewed By: kiranchandramohan

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

Only X86_64 and ARM64 have a reserved register for async arguments, and so the
debugger is only able to handle those targets. For other architectures, we use a
non-entry-value expression and let the debugger do its best with that.

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

We should also test the x86 target, since it has different backend defaults from
ARM.

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

My previous patch D151283 added a new option to llvm-cov to make it generate a hierarchical report for better view. This patch is to enable it for the coverage report of LLVM itself.

Reviewed By: phosek

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

Suppose we have a nested loop like this:

  void foo(int32_t *dst, int32_t *src, int m, int n) {
    for (int i = 0; i < m; i++) {
      for (int j = 0; j < n; j++) {
        dst[(i * n) + j] += src[(i * n) + j];
      }
    }
  }

We currently generate runtime memory checks as a precondition for
entering the vectorised version of the inner loop. However, if the
runtime-determined trip count for the inner loop is quite small
then the cost of these checks becomes quite expensive. This patch
attempts to mitigate these costs by adding a new option to
expand the memory ranges being checked to include the outer loop
as well. This leads to runtime checks that can then be hoisted
above the outer loop. For example, rather than looking for a
conflict between the memory ranges:

1. &dst[(i * n)] -> &dst[(i * n) + n]
2. &src[(i * n)] -> &src[(i * n) + n]

we can instead look at the expanded ranges:

1. &dst[0] -> &dst[((m - 1) * n) + n]
2. &src[0] -> &src[((m - 1) * n) + n]

which are outer-loop-invariant. As with many optimisations there
is a trade-off here, because there is a danger that using the
expanded ranges we may never enter the vectorised inner loop,
whereas with the smaller ranges we might enter at least once.

I have added a HoistRuntimeChecks option that is turned off by
default, but can be enabled for workloads where we know this is
guaranteed to be of real benefit. In future, we can also use
PGO to determine if this is worthwhile by using the inner loop
trip count information.

When enabling this option for SPEC2017 on neoverse-v1 with the
flags "-Ofast -mcpu=native -flto" I see an overall geomean
improvement of ~0.5%:

SPEC2017 results (+ is an improvement, - is a regression):
520.omnetpp: +2%
525.x264: +2%
557.xz: +1.2%
...
GEOMEAN: +0.5%

I didn't investigate all the differences to see if they are
genuine or noise, but I know the x264 improvement is real because
it has some hot nested loops with low trip counts where I can
see this hoisting is beneficial.

Tests have been added here:

  Transforms/LoopVectorize/runtime-checks-hoist.ll

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

Could use more work for vectors.

https://reviews.llvm.org/D156534

Currently we're getting away with post-selection constant folding on
these (a hack which exists for the DAG).

https://reviews.llvm.org/D156534

Dst is never used after creating the type making
these assignments dead

Reviewed by: arsenm
Differential Revision: https://reviews.llvm.org/D158610

When lowering a splat_vector_parts, if the hi bits are undefined then we can
splat the lo bits without having to check if it's going to be sign extended or
not, because those bits will be undefined anyway.

I've handled it for both fixed and scalable vectors, but there's no diff
on the scalable vror tests, since the hi bits aren't combined away to
undef in SimplifyDemanded for scalable vectors. I'm not sure why that is.

Reviewed By: craig.topper

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

This adds some more extensive test coverage for fneg through global isel,
switching the opcodes to use the more complete ActionDefinitions to handle more
cases.

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

Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D156865

[X86] fold-and-shift-x86_64.ll - add zext test case where upper bits are known zero (and won't get simplified to any_extend)

Add test coverage showing failure to use foldMaskAndShiftToScale with zero_extend nodes

When visiting load and store instructions in SROA skip scalable vectors.
This is relevant in the implementation of the 'arm_sve_vector_bits'
attribute that is used to define VLS types, similar to D85725.

Fix https://gcc.godbolt.org/z/o561P9zj4

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

This adds some more extensive test coverage for fmul through global isel,
switching the opcodes to use the more complete ActionDefinitions to handle more
cases.