As mentioned in llvm#68882 and
https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699

Gep arithmetic isn't consistent with different types. GVNSink didn't
realize this and sank all geps as long as their operands can be wired
via PHIs
in a post-dominator.

Fixes: llvm#85333
Reapply: llvm#88440 after fixing the non-determinism issues in llvm#90995

Adds the LLVM vector.deinterleave2 intrinsic to the MLIR LLVM dialect. The 
deinterleave2 intrinsic takes a vector and returns two vectors with the first 
having even elements and the second with odd elements from the input 
vector. The inverse of vector.interleave2.

MCOperand has a constructor that permits a nullptr MCInst, and BOLT makes use of that. Adjust MCOperand's dumper to permit such use.

Remove 'Valid' local boolean that has a single use, and return directly instead.

…#91933)

Given `foo...[idx]` if idx is value dependent, the expression is type
dependent.

Fixes llvm#91885
Fixes llvm#91884

Remove excess parentheses and use `boolean ? true-case : false-case` idiom.

When writing the test for this I seemingly forgot to put 'CHECK' on the
lines, so I didn't notice that I was printing the identifiers as
pointers rather than their names.  This patch corrects the tests and the
print behavior.

Closes llvm#91188

…92072)

Fixes llvm#92062

…0448)

This patch rewrites the ArmSME tile allocator to use liveness
information to make better tile allocation decisions and improve the
correctness of the ArmSME dialect. This algorithm used here is a linear
scan over live ranges, where live ranges are assigned to tiles as they
appear in the program (chronologically). Live ranges release their
assigned tile ID when the current program point is passed their end.
This is a greedy algorithm (which is mainly to keep the implementation
relatively straightforward), and because it seems to be sufficient for
most kernels (e.g. matmuls) that use ArmSME. The general steps of this
are roughly from
https://link.springer.com/content/pdf/10.1007/3-540-45937-5_17.pdf,
though there have been a few simplifications and assumptions made for
our use case.

Hopefully, the only changes needed for a user of the ArmSME dialect is
that:

- `-allocate-arm-sme-tiles` will no longer be a standalone pass 
  - `-test-arm-sme-tile-allocation` is only for unit tests 
- `-convert-arm-sme-to-llvm` must happen after `-convert-scf-to-cf` 
   - SME tile allocation is now part of the LLVM conversion

By integrating this into the `ArmSME -> LLVM` conversion we can allow
high-level (value-based) ArmSME operations to be side-effect-free, as we
can guarantee nothing will rearrange ArmSME operations before we emit
intrinsics (which could invalidate the tile allocation).

The hope is for ArmSME operations to have no hidden state/side effects
and allow easily lowering dialects such as `vector` and `arith` to SME,
without making assumptions about how the input IR looks, as the
semantics of the operations will be the same. That is no (new) side
effects and the IR follows the rules of SSA (a value will never change).

The aim is correctness, so we have a base for working on optimizations.

A buildbot with expensive checks enabled flagged some problems with my patch. There was also a post-commit nit on the langref changes.

…m#92004)

This makes the `vc-rev-enabled` feature unsupported if we fail to
retrieve the git revision for any reason, such as if git is not
installed.

…straints (llvm#92104)

Clangd uses it to determine whether the argument is within the selection
range.

Fixes clangd/clangd#2033

…filename and location info (llvm#92050)

PR llvm#80680 added bits in the codegen to lazily add convergence intrinsics
when required. This logic relied on the LoopStack. The issue is when
parsing the condition, the loopstack doesn't yet reflect the correct
values, as expected since we are not yet in the loop.

However, convergence tokens should sometimes already be available. The
solution which seemed the simplest is to greedily generate the tokens
when we generate SPIR-V.

Fixes llvm#88144

---------

Signed-off-by: Nathan Gauër <brioche@google.com>

Now that we've got (minus some issues around datatypes and invariant
loads) working lowerings for address space 7, update the table in the
AMDGPU usage guide to properly indicate the nature of these address
spaces.

…llvm#92067)

cm.push can't save X26 without also saving X27. This removes two other
checks for this case.

This causes CFI to be emitted since X27 is now explicitly a callee saved
register.

The affected tests use inline assembly to clobber X26 rather than the
whole range of s0-s10.

Allow mixing objects with/without signed class ro data and category
class properties as long as it happens before we register the metadata.
These combinations are a warning in ld, not a hard error. The only case
that is ABI-breaking is if we already registered with the feature
enabled but later try to load an object that doesn't support it.

rdar://127336061

…inations of 32-bit integers. NFC

tryToCreateDiffCheck has one caller, and exits early if CanUseDiffCheck
is false. Hence, we can get/set CanUseDiffCheck in the caller to avoid
wastefully calling tryToCreateDiffCheck. This patch is an NFC
simplification of program logic.

The target combine is no longer required because InstCombine will
transform the DIV by a power of 2 into a multiply, so in practice
this case will never trigger.

Additionally, the generated code would have been incorrect for
streaming(-compatible) functions, because it assumed NEON was available.

…lvm#92086)

self.wait_for_running_event(process) is always called after
self.runCmd("continue"). It is strange to expect eStateConnected here.
This test failed in case of a remote target. The correct state is
eStateRunning. Removed incorrect checking.

)

The cost of `experimental.cttz.elts` in RISC-V equals to the cost of
vfirst when the zero_is_poison argument is true. Otherwise, we add
additional costs of cmp + select to convert the -1 result from vfirst to
EVL.

…#90500)

Currently, clang postpones all semantic analysis of unary operators with
operands of pointer/pointer to member/array/function type until
instantiation whenever that type is dependent (e.g. `T*` where `T` is a
type template parameter). Consequently, the uninstantiated AST nodes all
have the type `ASTContext::DependentTy` (which, for the purposes of
llvm#90152, is undesirable as that type may be the current instantiation!
(e.g. `*this`))

This patch moves the point at which we perform semantic analysis for
such expression to be prior to instantiation.

llvm#91137 reverted in llvm#92001

A build error fix added in 28d5ece

---------

Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com>

Most diagnostics obey
https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
but some diverge. Fix them.

While here, adjust some diagnostics.

Pull Request: llvm#92024

Currently, only those global variables which are at compile unit scope
are added to the 'globals' list of the DICompileUnit. This does not work
for languages which support modules (e.g. Fortran) where hierarchy
can be
variable -> module -> compile unit.

To fix this, if a variable scope points to a module, we walk one level
up and see if module is in the compile unit scope.

This was initially part of llvm#91582 which adds debug information for
Fortran module variables. @kiranchandramohan pointed out that MLIR
changes should go in separate PRs.

These larger SEWs aren't in the ratified V spec. Thanks to dzaima and
sorear on IRC for pointing this one out.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

…hCond from versionCallSite (llvm#81181)

* This is to be used by llvm#81378
to implement a variant of versionCallSite that compares vtables.
* The parent patch is llvm#81051

…idening-of-multiplication-result (llvm#92025)

When expression got errors (missing typedef) and clang-tidy is compiled
with asserts enabled, then we crash in this check on assert because type
with errors is visible as an dependent one. This is issue caused by
invalid input.

But as there is not point to crash in such case and generate additional
confusion, such expressions with errors will be now ignored.

Fixes llvm#89515, llvm#55293

…rs (llvm#90500)" (llvm#92149)

This reverts commit 8019cbb.

Test courtesy to @bjope showing a regression due to
ecae3ed.

Although we can't reduce the number of instructions, if we selected `li
rd, -1` instead then this could be encoded in a 16-bit instruction.

…nstants (llvm#92131)

This follows the same pattern as 20e6265. Although we
can't reduce the number of instructions used, if we are able to use a
sign-extended 6-bit immediate then the 16-bit c.li instruction can be
selected (thus saving code size). Although this _could_ be gated so it
only happens if C is enabled, I've opted not to because at worst it's
neutral and it doesn't seem helpful to add unnecessary divergence
between the RVC and non-RVC paths.

There are cases where a vector value has some users that demand the
the single scalar value only (NeedsScalar), while other users demand the
vector value (see attached test cases). In those cases, the NeedsScalar
users should only demand the first lane.

Fixes llvm#91883.

Prior to this, fixed point multiplication would lead to this assertion
error on AArhc64, armv8, and armv7.

```
 _Accum f(_Accum x, _Accum y) { return x * y; }

// ./bin/clang++ -ffixed-point /tmp/test2.cc -c -S -o - -target aarch64 -O3
clang++: llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:10245: void llvm::TargetLowering::forceExpandWideMUL(SelectionDAG &, const SDLoc &, bool, EVT, const SDValue, const SDValue, const SDValue, const SDValue, SDValue &, SDValue &) const: Assertion `Ret.getOpcode() == ISD::MERGE_VALUES && "Ret value is a collection of constituent nodes holding result."' failed.
```

This path into forceExpandWideMUL should only be taken if we don't
support [US]MUL_LOHI or MULH[US] for the operand size (32 in this case).
But we should also check if we can just leverage regular wide
multiplication. That is, extend the operands from 32 to 64, do a regular
64-bit mul, then trunc and shift. These ops are certainly available on
aarch64 but for wider types.

…ts (llvm#91850)

This PR is in preparation to some extensions to the
`InferIntRangeInterface` around the `nsw` and `nuw` flags supported in
the `arith` dialect and LLVM.

We provide some common inference logic for `index` and `arith` in
`InferIntRangeCommon.h` but our Test Ops are currently fixed to `Index`
Types. As we test the range inference for arith Ops, especially around
the overflow behaviour, it's handy to have native support for the
typical integer types in the test Ops.

This patch
1. Changes the Attributes of `test.with_bounds` ops from `Index` to
`APInt` which matches the internal representation in
`ConstantIntRanges`.
2. Allows the use of `AnyInteger` in addition to `Index` for the
operands and results of the test Ops. This now requires explicit
specification of the type in the IR, where before `Index` was implicit.
3. Requires bounds Attrs to be specified in the precision of the SSA
value, eliminating any implicit truncation or extension. (*Could this
lead to problems?*)

)

This change allows us to pass creduce options to creduce-clang-crash.py
script. With this, `--n` is no longer needed to specify the number of
cores, so removed the flag.

The motivation is
llvm#87933 (comment)
suggests that disabling creduce renaming passes helps people to further
reduce crash manually.

Applying the loop guards to the distance may prevent
isSafeDependenceDistance from determining NoDep, unless loop guards are
also applied to the backedge-taken-count.

Instead of applying the guards to both Dist and the
backedge-taken-count, just apply them after handling
isSafeDependenceDistance and constant distances; there is no benefit to
applying the guards before then.

This fixes a regression flagged by @bjope due to
ecae3ed.

Summary:
The offload library supports basic JIT functionality, however we
currently link against every single target even though only AMDGPU and
NVPTX are supported. This somewhat bloats the dynamic library list, so
we should constrain it to what's actually used.

I'm interested in being CC'd on these changes

Add test cases for
llvm#89958.

…nctions. (llvm#91643)

The existing code is checking for the presence of the +sve subtarget
feature
when deciding to use a base pointer for the function, but this check
doesn't
work when only +sme is used.

rdar://126878490

…written for class/variable template specializations (llvm#81642)" (llvm#91393)

Reapplies llvm#81642, fixing the crash which occurs when running the lldb test suite.

llvm#92158)

…ducer.

This mirrors the LLDB_DEBUGSERVER_PATH environment variable and allows
you to have lldb-argdumper in a non-standard location and still use it
at runtime.

…del (llvm#92032)

SubtargetEmitter::GenSchedClassTables takes a CodeGenProcModel, but
calls hasReadOfWrite which loops over all ProcModels. We move
hasReadOfWrite to CodeGenProcModel and remove the loop over all
ProcModels. This leads to a 144% speedup on the RISC-V backend of our
downstream.

As we have debuginfod as symbol locator available in lldb now, we want
to make full use of it.
In case of post mortem debugging, we don't always have the main
executable available.
However, the .note.gnu.build-id of the main executable(some other
modules too), should be available in the core file, as those binaries
are loaded in memory and dumped in the core file.

We try to iterate through the NT_FILE entries, read and store the gnu
build id if possible. This will be very useful as this id is the unique
key which is needed for querying the debuginfod server.

Test:
Build and run lldb. Breakpoint set to
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147
Verified after this commit, module_uuid is the correct gnu build id of
the main executable which caused the crash(first in the NT_FILE entry)

Reverts llvm#92078

…91486)

Type unit DIE generated by clang contains DW_AT_comp_dir/DW_AT_dwo_name.
This was added to clang to help LLDB to figure out where type unit come
from when accessing an entry in a .debug_names accelerator table and
type units in .dwp file.

When BOLT writes out .dwo files it changes the name of them. User can
also specify directory of where they can be written out. Added support
to BOLT to update those attributes.

After patch llvm#88805

`I` Ext will be added automatically when we running the command like 
`./build/bin/llc -mtriple=riscv32 -mattr=+e -target-abi ilp32e
-verify-machineinstrs llvm/test/CodeGen/RISCV/zcmp-additional-stack.ll`

it will generate 
```
	.text
	.attribute	4, 16
	.attribute	5, "rv32i2p1_e2pe"
	.file	"zcmp-additional-stack.ll"
	.globl	func                            # -- Begin function func
	.p2align	1
	.type	func,@function
```

This patch reset the I ext in FeatureBit when `+e` has been specify

NFC. Makes the VOP1Inst_t16 interface more generic to support future
instructions cleanly.

…n of VP_FSHL/FSHR. NFC

There's a special path when the promoted type has an element size
more than twice the size of the original type.

Summary:
One of the downsides of the linker wrapper is that it made debugging
more difficult. It is very powerful in that it can resolve a lot of
input matching and library handling that could not be done before.
However, the old method allowed users to simply copy-paste the script
files to modify the output and test it.

This patch attempts to make it easier to debug changes by letting the
user override all the linker inputs. That is, we provide a user-created
binary that is treated like the final output of the device link step.
The intended use-case is for using `-save-temps` to get some IR, then
modifying the IR and sticking it back in to see if it exhibits the old
failures.

Utility converting a profile coming from `compiler_rt` to bitstream, and
a reader.

`PGOCtxProfileWriter::write` would be used as the `Writer` parameter for
`__llvm_ctx_profile_fetch` API. This is expected to happen in user code,
for example in the RPC hanler tasked with collecting a profile, and
would look like this:

```
// set up an output stream "Out", which could contain other stuff
{
  // constructing the Writer will start the section, in Out, containing
  // the collected contextual profiles.
  PGOCtxProfWriter Writer(Out);
  __llvm_ctx_profile_fetch(&Writer, +[](void* W, const ContextNode &N) {
    reinterpret_cast<PGOCtxProfWriter*>(W)->write(N);
  });
  // Writer going out of scope will finish up the section.
}
```

The reader produces a data structure suitable for maintenance during IPO
transformations.

Reverts llvm#91859

Buildbot failures.

…ttening loops (llvm#86961)

When flattening the loop, if the GEP was inbound, it should stay
inbound, because the only thing that changed is how the pointers are
calculated, not the elements being accessed.

Proof: https://alive2.llvm.org/ce/z/dApMpQ

Avoid including MD5.h in a core IR header.

… before consuming it

Close llvm#91418

Since we load the variable's initializers lazily, it'd be problematic
if the initializers dependent on each other. So here we try to load the
initializers of static variables to make sure they are passed to code
generator by order. If we read any thing interesting, we would consume
that before emitting the current declaration.

Spec reference: https://cdrdv2.intel.com/v1/dl/getContent/678938

…ariables before consuming it"

This reverts commit 11b0591.

The premerge bot is broken.

The ExceptionDemo example was no longer compiling (since llvm 14 at
least). The PR makes the example work with the current API and also
transition from MCJIT to ORC.
Fixes llvm#63702

Split off from llvm#70549, this patch moves RISCVInsertVSETVLI to after phi
elimination where we exit SSA and need to move to LiveVariables.

The motivation for splitting this off is to avoid the large scheduling
diffs from moving completely to after regalloc, and instead focus on
converting the pass to work on LiveIntervals.

The two main changes required are updating VSETVLIInfo to store VNInfos
instead of MachineInstrs, which allows us to still check for PHI defs in
needVSETVLIPHI, and fixing up the live intervals of any AVL operands
after inserting new instructions.

On O3 the pass is inserted after the register coalescer, otherwise we
end up with a bunch of COPYs around eliminated PHIs that trip up
needVSETVLIPHI.

Co-authored-by: Piyou Chen <piyou.chen@sifive.com>

The following small thing caught my eye:

1) `EILSEQ` is not part of the generic asm error number macros. See the
[full list of generic asm errno
codes](https://github.com/torvalds/linux/blob/4b95dc87362aa57bdd0dcbad109ca5e5ef3cbb6c/include/uapi/asm-generic/errno-base.h).
AFAIK the generic asm errno numbers are common between different
operating systems and architectures. `EILSEQ` is not part of this common
set of errno's.

2) `EILSEQ`'s value is wrong. During the addition of `EILSEQ` in
https://reviews.llvm.org/D151129, the value `35` was probably chosen as
its the consecutive number. This is not correct. The actual values can
be looked up for example here:
* [For Linux
kernel](https://github.com/search?q=repo%3Atorvalds%2Flinux+EILSEQ&type=code&p=1):
`EILSEQ = 84` (uapi; i.e. x86_64), `EILSEQ = 88` (mips), `EILSEQ = 47`
(parisc)
* [For Darwin
kernel](https://github.com/apple-oss-distributions/xnu/blob/main/bsd/sys/errno.h#L237):
`EILSEQ = 92`

…m#92051)

As in the title, fixes llvm#91934

The middle end will remove the inner vsetvli otherwise, and it's more
typical to set the AVL to the remaining VL.

This also prevents the test from showing up as a regression in llvm#91319

Even as the NPM has been in use by Polly for a while now, the
majority of the tests continue using the LPM passes. This patch
ports the tests to use the NPM passes (for example, by replacing
a flag such as -polly-detect with -passes=polly-detect following
the NPM syntax for specifying passes) with some exceptions for
some missing features in the new passes. Additionally, the lit
substitution %loadPolly is replaced by the substitution of what
was %loadNPMPolly and %loadNPMPolly is removed.

This was looking through an addrspacecast, and not finding a later
unfoldable cast to another address space. Fixes improperly deleting
a required alloca + memcpy and introducing an illegal addrspacecast.
    
This also required fixing some worklist management issues with
addrspacecast, and assuming that only memcpy sources could need
replacement.
    
Regresses one test function, but this looks like it optimized
before by accident. It never saw the pointer use by the call
to readonly_callee, which should require insertion of a new cast.
    
Fixes llvm#68120

Reverts llvm#90632.

Causing failures on buildbots that dynamically load polly. Reverting
while we sort it out.

…al in WebKit checkers. (llvm#91873)

Also allow CXXBindTemporaryExpr, which creates a temporary object with a
non-trivial destructor, and add a few more std and WTF functions to the
explicitly allowed list.

Introduced in llvm#91150. Not
needed anymore as llvm#92041 fixed
the root cause. `ENAMETOOLONG` and `EOVERFLOW` are well defined in
`<linux/errno.h>`.

Post mortem: Due to the previously missing inclusion of
`<linux/errno.h>` (fixed with
llvm#92041), I misinterpreted an
undefined macro issue during the development of
llvm#91150 as being caused by a
missing definition rather than by the missing inclusion of the linux
header. I realized too late that `ENAMETOOLONG` and `EOVERFLOW` were
correctly defined in `<linux/errno.h>` and that it was my missing
inclusion that caused the problem.

Prefer to emit the intrinsic over a libcall in the
intrinsic or no-math-errno case.

…llvm#92120)

This commit extends the verifier for atomics to properly verify larger
types. Beforehand, the verifier strictly rejected larger integer types,
while it now consults the data layout to determine if their bitsize is a
power of two. This behavior reflects what LLVM's verifier is checking
for.

When expanding an L128 (which is used to reload i128) it is
possible that the quadword destination register clobbers an
address register. This patch adds an assertion against the case
where both of the expanded parts clobber the address, and in the
case where one of the expanded parts do so puts it last.

Fixes llvm#91437

…ttribute. (llvm#91732)

`disable_sanitizer_instrumetation` is attached to functions that shall
not be instrumented e.g. ifunc resolver because those run before
everything is initialised.
Some sanitizer already handles this attribute, this patch adds it to
DataFLow and Coverage too.

...which caused issues like

> ==42==ERROR: AddressSanitizer failed to deallocate 0x32 (50) bytes at
address 0x117e0000 (error code: 28)
> ==42==Cannot dump memory map on emscriptenAddressSanitizer: CHECK
failed: sanitizer_common.cpp:81 "((0 && "unable to unmmap")) != (0)"
(0x0, 0x0) (tid=288045824)
> #0 0x14f73b0c in __asan::CheckUnwind()+0x14f73b0c
(this.program+0x14f73b0c)
> #1 0x14f8a3c2 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)+0x14f8a3c2
(this.program+0x14f8a3c2)
> #2 0x14f7d6e1 in __sanitizer::ReportMunmapFailureAndDie(void*,
unsigned long, int, bool)+0x14f7d6e1 (this.program+0x14f7d6e1)
> #3 0x14f81fbd in __sanitizer::UnmapOrDie(void*, unsigned
long)+0x14f81fbd (this.program+0x14f81fbd)
> #4 0x14f875df in __sanitizer::SuppressionContext::ParseFromFile(char
const*)+0x14f875df (this.program+0x14f875df)
> #5 0x14f74eab in __asan::InitializeSuppressions()+0x14f74eab
(this.program+0x14f74eab)
> #6 0x14f73a1a in __asan::AsanInitInternal()+0x14f73a1a
(this.program+0x14f73a1a)

when trying to use an ASan suppressions file under Emscripten: Even
though it would be considered OK by SUSv4, the Emscripten runtime states
"We don't support partial munmapping" (see

<emscripten-core/emscripten@f4115eb>
"Implement MAP_ANONYMOUS on top of malloc in STANDALONE_WASM mode
(llvm#16289)").

Co-authored-by: Stephan Bergmann <stephan.bergmann@allotropia.de>

Since the set of COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION is removed in
commit 8421fa5,
cleanup the use of COMPILER_RT_ASAN_SHADOW_SCALE_DEFINITION.

…m#92093)

The stack validation heuristic is counter-productive in this case, as
the unaligned address is most likely the thing that caused the signal in
the first place.

This is already in a if(isBlockPointer()) block.

Just create a local variable for them.

…1531)

There are many environments where `errno` is a macro that expands to
something like `(*__errno())` (different standard library
implementations use different names instead of "__errno").

In these environments the ErrnoModeling checker creates a symbolic
region which will be used to represent the return value of this "get the
location of errno" function.

Previously this symbol was only created when the checker was able to
find the declaration of the "get the location of errno" function; but
this commit eliminates the complex logic that was responsible for this
and always creates the symbolic region when `errno` is not available as
a "regular" global variable.

This significantly simplifies a code and only introduces a minimal
performance reduction (one extra symbol) in the case when `errno` is not
declared (neither as a variable nor as a function).


In addition to this simplification, this commit specifies that the
`CallDescription`s for the "get the location of errno" functions are
matched in `CDM::CLibrary` mode. (This was my original goal, but I was
sidetracked by resolving a FIXME above the `CallDescriptionSet` in
`ErrnoModeling.cpp`.)

This change is very close to being NFC, but it fixes weird corner cases
like the handling of a C++ method that happens to be named "__errno()"
(previously it could've been recognized as an errno location getter
function).

I though the test could work there as well, but (of course) it does not,
because the lowest bit just means "run the code as thumb".

…lvm#92156)

Arguments to openmp regions should not be tagged as dummy arguments.
This is particularly unsafe because these openmp blocks will eventually
be inlined into the calling function, where they will trivially alias
with other values inside of the calling function.

This is probably a theoretical issue because the calls to openmp runtime
function calls would act as barriers, preventing optimizations that are
too aggressive. But a lot more thought would need to go into a bet like
that.

This came out of discussion on
llvm#92036