There's an unfortunate collision between two features:
 - we implicitly cancel certain requests when the file changes, to avoid
   the queue getting clogged building old revisions to service stale requests
 - we "reparse-if-needed" by synthesizing a file change, e.g. on didSave

We could explicitly mark these synthetic requests to avoid this, but
looking for changes in file content clutters our APIs less and is
arguably the correct thing to do in any case.

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

inserted when the original call had a 'returned' argument

The code is testing whether the instruction BBI points to is the call
that is paired up with the retainRV/claimRV call, but it doesn't work
when the call has a 'returned' argument since GetArgRCIdentityRoot looks
through 'returned' arguments.

rdar://72485383

Support VM and VMP registers in copyPhysReg() function.  Also add
regression tests.

Reviewed By: simoll

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

Different cases were using a bunch of different variants of the printing policy.
Each of these had something going for it, but the result was inconsistent.

Goals:
  - single printing policy used (almost) everywhere
  - avoid unidiomatic tags like `class vector<class X>`
  - be informative and easy to understand

For tags, the solution I wound up with is: we print only the outer tag and only
in the simplest cases where this elaboration won't cause confusion.

For example:
 - class X
 - enum Foo
 - vector<int>
 - X*

This seems to strike a nice balance of providing plenty of info/context in common
cases while never being confusing.

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

We need to make sure not to emit R_X86_64_GOTPCRELX relocations for
instructions that use a REX prefix. If a REX prefix is present, we need to
instead use a R_X86_64_REX_GOTPCRELX relocation. The existing logic for
CALL64m, JMP64m, etc. already handles this by checking the HasREX parameter
and using it to determine which relocation type to use. Do this for all
instructions that can use relaxed relocations.

Reviewed By: MaskRay

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

This doesn't actually work (any more?), and instead renders as a literal
$Date$ on the website.

support yet.

To support OpenCL, which typically uses SPIR as an IR, non-zero address
spaces must be accounted for. This patch makes the RISC-V target assume
no-op address space casts across the board, which effectively removes
the need to support addrspacecast instructions in the backend.

For a RISC-V implementation with different configurations or specialized
address spaces where casts aren't no-ops, the function can be adjusted
as required.

Reviewed By: jrtc27

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

Patch by: Aditya Kumar.

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

This patch adds two IR intrinsics for vsetvli instruction. One to set the vector length to a user specified value and one to set it to vlmax. The vlmax uses the X0 source register encoding.

Clang builtins will follow in a separate patch

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

[TableGen] Fix D90844 introduced non-determinism due to iteration over a std::map over allocated object pointers

993eaf2d (D90844) is still wrong.
The allocated const Record* pointers do not have an order guarantee
so switching from DenseMap to std::map does not help.

ProcModelMapTy = std::map<const Record*, unsigned>

Sort the values instead.

The default behavior for any_extend of a constant is to zero extend.
This occurs inside of getNode rather than allowing type legalization
to promote the constant which would sign extend. By using sign extend
with getNode the constant will be sign extended. This gives a better
chance for isel to find a simm5 immediate since all xlen bits are
examined there.

For instructions that use a uimm5 immediate, this change only affects
constants >= 128 for i8 or >= 32768 for i16. Constants that large
already wouldn't have been eligible for uimm5 and would need to use a
scalar register.

If the instruction isn't able to use simm5 or the immediate is
too large, we'll need to materialize the immediate in a register.
As far as I know constants with all 1s in the upper bits should
materialize as well or better than all 0s.

Longer term we should probably have a SEW aware PatFrag to ignore
the bits above SEW before checking simm5.

I updated about half the test cases in some tests to use a negative
constant to get coverage for this.

Reviewed By: evandro

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

MSSA DSE starts at a killing store, finds an earlier store and
then checks that the earlier store is not read along any paths
(without being killed first). However, it uses the memory location
of the killing store for that, not the earlier store that we're
attempting to eliminate.

This has a number of problems:

* Mismatches between what BasicAA considers aliasing and what DSE
  considers an overwrite (even though both are correct in isolation)
  can result in miscompiles. This is PR48279, which D92045 tries to
  fix in a different way. The problem is that we're using a location
  from a store that is potentially not executed and thus may be UB,
  in which case analysis results can be arbitrary.
* Metadata on the killing store may be used to determine aliasing,
  but there is no guarantee that the metadata is valid, as the specific
  killing store may not be executed. Using the metadata on the earlier
  store is valid (it is the store we're removing, so on any execution
  where its removal may be observed, it must be executed).
* The location is imprecise. For full overwrites the killing store
  will always have a location that is larger or equal than the earlier
  access location, so it's beneficial to use the earlier access
  location. This is not the case for partial overwrites, in which
  case either location might be smaller. There is some room for
  improvement here.

Using the earlier access location means that we can no longer cache
which accesses are read for a given killing store, as we may be
querying different locations. However, it turns out that simply
dropping the cache has no notable impact on compile-time.

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

This time with tests.

Original message:
Similar to D93365, but for floating point. No need for special ISD opcodes
though. We can directly isel these from intrinsics. I had to use anyfloat_ty
instead of anyvector_ty in the intrinsics to make LLVMVectorElementType not
crash when imported into the -gen-dag-isel tablegen backend.

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

This reverts commit 46a40c4b.

I forgot to git add the tests.

Similar to D93365, but for floating point. No need for special ISD opcodes
though. We can directly isel these from intrinsics. I had to use anyfloat_ty
instead of anyvector_ty in the intrinsics to make LLVMVectorElementType not
crash when imported into the -gen-dag-isel tablegen backend.

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

This adds intrinsics for vmv.x.s and vmv.s.x.

I've used stricter type constraints on these intrinsics than what we've been doing on the arithmetic intrinsics so far. This will allow us to not need to pass the scalar type to the Intrinsic::getDeclaration call when creating these intrinsics.

A custom ISD is used for vmv.x.s in order to implement the change in computeNumSignBitsForTargetNode which can remove sign extends on the result.

I also modified the MC layer description of these instructions to show the tied source/dest operand. This is different than what we do for masked instructions where we drop the tied source operand when converting to MC. But it is a more accurate description of the instruction. We can't do this for masked instructions since we use the same MC instruction for masked and unmasked. Tools like llvm-mca operate in the MC layer and rely on ins/outs and Uses/Defs for analysis so I don't know if we'll be able to maintain the current behavior for masked instructions. So I went with the accurate description here since it was easy.

Reviewed By: frasercrmck

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

The function was introduced on Aug 25, 2016 in commit
5f0d0e60.

Its last use was removed on Sep 13, 2017 in commit
dfa8741c.

This patch enables canonicalization of SPF_ABS and SPF_ABS
to the abs intrinsic.

This is a recommit, the original try was
05d4c4eb,
but it was reverted due to an apparent miscompile,
which since then has just been fixed by the previous commit.

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

The transform wasn't checking that the LHS of the comparison
*is* the `X` in question...
This is the miscompile that was holding up D87188.

Thanks to Dave Green for producing an actionable reproducer!

Thanks to Dave Green for producing an actionable reproducer!
It is (obviously) a miscompile:
```
----------------------------------------
define i32 @select_abs_of_abs_eq_wrong(i32 %x, i32 %y) {
%0:
  %abs = abs i32 %x, 0
  %neg = sub i32 0, %abs
  %cmp = icmp eq i32 %y, 0
  %sel = select i1 %cmp, i32 %neg, i32 %abs
  ret i32 %sel
}
=>
define i32 @select_abs_of_abs_eq_wrong(i32 %x, i32 %y) {
%0:
  %abs = abs i32 %x, 0
  ret i32 %abs
}
Transformation doesn't verify!
ERROR: Value mismatch

Example:
i32 %x = #xe0000000 (3758096384, -536870912)
i32 %y = #x00000000 (0)

Source:
i32 %abs = #x20000000 (536870912)
i32 %neg = #xe0000000 (3758096384, -536870912)
i1 %cmp = #x1 (1)
i32 %sel = #xe0000000 (3758096384, -536870912)

Target:
i32 %abs = #x20000000 (536870912)
Source value: #xe0000000 (3758096384, -536870912)
Target value: #x20000000 (536870912)

Alive2: Transform doesn't verify!

```

The main change is to add a 'IsDecl' field to DIModule so
that when IsDecl is set to true, the debug info entry generated
for the module would be marked as a declaration. That way, the debugger
would look up the definition of the module in the gloabl scope.

Please see the comments in llvm/test/DebugInfo/X86/dimodule.ll
for what the debug info entries would look like.

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

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

[AIX] Change the code based on https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20201214/864235.html

Summary:

change the code based on the discussion as:
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20201214/864235.html

Temporarily revert commit 8b1c4e31.

After 8b1c4e31 the compile-time for `MultiSource/Benchmarks/MiBench/consumer-lame`
dramatically increases with -O3 & LTO, causing issues for builders with
that configuration.

I filed PR48553 with a smallish reproducer that shows a 10-100x compile
time increase.

We work with @rogfer01 from BSC to come out this patch.

Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Craig Topper <craig.topper@sifive.com>

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

Similar to D69312, and documented in D69839, the IRBuilder needs to add
the strictfp attribute to invoke instructions when constrained floating
point is enabled.

This is try 2, with the test corrected.

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

This PR implements the function splitBasicBlockBefore to address an
issue
that occurred during SplitEdge(BB, Succ, ...), inside splitBlockBefore.
The issue occurs in SplitEdge when the Succ has a single predecessor
and the edge between the BB and Succ is not critical. This produces
the result ‘BB->Succ->New’. The new function splitBasicBlockBefore
was added to splitBlockBefore to handle the issue and now produces
the correct result ‘BB->New->Succ’.

Below is an example of splitting the block bb1 at its first instruction.

/// Original IR
bb0:
	br bb1
bb1:
        %0 = mul i32 1, 2
	br bb2
bb2:
/// IR after splitEdge(bb0, bb1) using splitBasicBlock
bb0:
	br bb1
bb1:
	br bb1.split
bb1.split:
        %0 = mul i32 1, 2
	br bb2
bb2:
/// IR after splitEdge(bb0, bb1) using splitBasicBlockBefore
bb0:
	br bb1.split
bb1.split
	br bb1
bb1:
        %0 = mul i32 1, 2
	br bb2
bb2:

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

According to the documentation, if a spill is required to make a
register available and AllowSpill is false, then NoRegister should be
returned, however, this scenario was actually triggering an assertion
failure.

This patch moves the assertion after the handling of AllowSpill.

Authored by: Lewis Revill

Reviewed By: arsenm

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

The SROA pass tries to be lazy for removing dead instructions that are collected during iterative run of the pass in the DeadInsts list.  However it does not remove instructions from the dead list while running eraseFromParent() on those instructions.

This causes (rare) null pointer dereferences.  For example, in the speculatePHINodeLoads() instruction, in the following code snippet:

```
   while (!PN.use_empty()) {
     LoadInst *LI = cast<LoadInst>(PN.user_back());
     LI->replaceAllUsesWith(NewPN);
     LI->eraseFromParent();
   }
```

If the Load instruction LI belongs to the DeadInsts list, it should be removed when eraseFromParent() is called.  However, the bug does not show up in most cases, because immediately in the same function, a new LoadInst is created in the following line:

```
LoadInst *Load = PredBuilder.CreateAlignedLoad(
         LoadTy, InVal, Alignment,
         (PN.getName() + ".sroa.speculate.load." + Pred->getName()));
```

This new LoadInst object takes the same memory address of the just deleted LI using eraseFromParent(), therefore the bug does not materialize.  In very rare cases, the addresses differ and therefore, a dangling pointer is created, causing a crash.

Reviewed By: lebedev.ri

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

The scope of R_TLS (TP offset relocation types (TPREL/TPOFF) used for the
local-exec TLS model) is actually narrower than its name may imply. R_TLS_NEG
is only used by Solaris R_386_TLS_LE_32.

Rename them so that they will be less confusing.

Reviewed By: grimar, psmith, rprichard

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

Markdown formatting seems to now be available, reflowing the doc without changing any content.