Have the ErrorInfo version call it after looking up ErrorInfo in
the Operands.

Use the new function in a few places that don't have ErrorInfo and
were also generating out of range messages.

When a signal is raised before HWASAN has a chance to initialize it's TLS entry the program crashes. This only happens when hwasan-with-tls is true, which is default value. This patch fixes the problem by disabling signals during thread initialization time.

Reviewed By: vitalybuka

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

I think RISCV was the original here and the CSKY and Loong copied it.

The various isKnownNever* calls can be merged into one. This also introduces
the new ability to remove zero/sub/normal checks. Also start passing the
AssumptionCache arguments.

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

This resolves issues with running out of stack on examples like
https://fortran-lang.discourse.group/t/modern-fortran-sample-code/2019/18
reported by @clementval.

When target rewrite creates alloca(s) around a call, we need to insert
stacksave/stackrestore to free the allocated stack. Better performant
code may be achieved by placing the alloca(s) outside of loops,
but the placement has to behave correctly with regards to OpenMP/OpenACC/etc.
dialect operations that have special representation for "private"
objects. This is a concervative fix for correctness issue.

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

This is useful in contexts where you have multiple languages in play:
You may be stopped in a frame for language A, but want to set a watchpoint
with an expression using language B. The current way to do this is to
use the setting `target.language` while setting the watchpoint and
unset it after the watchpoint is set, but that's kind of clunky and
somewhat error-prone. This should add a better way to do this.

rdar://108202559

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

Zicntr and Zihpm are names for groups of CSRs so they should imply
that CSRs exist.

Reviewed By: asb, kito-cheng

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

This change adds the definition of the two extensions, but does not either a) make any register definitions conditional on them or b) enabled the extensions by default.

This is somewhat analogous to https://reviews.llvm.org/D143953, but with some key differences.  The best discussion I can find on status is here: https://github.com/riscv/riscv-profiles/issues/43.  These were removed between document version 2.1 and 2.2, but were not defined as new extensions in 2.2.  That addition came later - in March 2022.

According to https://drive.google.com/file/d/1qa57pePesOiDOrNzxuuGFhCL4Rbi9AYB/view these were ratified in March 2023.

Reviewed By: asb, reames

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

Makes assumes work for this case.

This patch adds lowering of TargetOps for the host. The lowering outlines the
target region function and uses the OpenMPIRBuilder support functions to emit
the function and call. Code generation for offloading will be done in later
patches.

Reviewed By: kiranchandramohan, jdoerfert, agozillon

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

We need to expand the set of possible classes to the opposite
sign for the first operand if we don't know the sign of the second
operand.

- The set of flag is from https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands

Before:
- ARM64 GCC supports flag output constraints, while Clang doesn't parse condition code, as shown in https://gcc.godbolt.org/z/7jzMEK796
- LLVM ISel won't lower them either (as shown in https://gcc.godbolt.org/z/Pv4PPf56c)

After:
- Given flag output constraints in LLVM IR, condition code is parsed and flag output is lowered to 'cset'.
- Clang parse is not added in this patch.

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

Downstream doc tooling doesn't like an #if between the doc and the
function prototype. This change also guarantees that the prototype
stays the same for 32/64 bit users.

Prior to this patch the SCS prologue used the following instruction
sequence.

```
s[w|d]  ra, 0(gp)
addi    gp, gp, [4|8]
```

The problem with this sequence is that an interrupt occurring between the
store and the increment could clobber the value just written to the SCS.

https://reviews.llvm.org/D84414#inline-813203 pointed out a similar
issues that could have affected the epilogue.

This patch changes the instruction sequence in the prologue to:

```
addi    gp, gp, [4|8]
s[w|d]  ra, -[4|8](gp)
```

The downside to this is that there is now a data dependency between the
add and the store.

Reviewed By: asb

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

So far we've relied on AllocaOp to represent the dummy arguments
not declared for the current entry. With HLFIR we have to account
for hlfir::DeclareOp.

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

Adds an interface to remove a string function attribute attached to a
CallBase, and a corresponding unittest.

This was extracted from D141077, and will be used by a follow on patch
that removes memprof attributes when needed.

Reviewed By: snehasish

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

This patch updates some of the documentation for the GPU libc project.
There is a lot of work still to be done, but this sets the general
outline.

Reviewed By: jdoerfert

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

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

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

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

clang-rename on a non existing file segfaults

Command to run -
$ clang-rename -offset=0 -new-name=plop asdasd

Error while processing llvm-project/asdasd.
clang-rename: llvm-project/llvm/include/llvm/Support/ErrorOr.h:237:
llvm::ErrorOr<T>::storage_type* llvm::ErrorOr<T>::getStorage()
[with T = const clang::FileEntry*; llvm::ErrorOr<T>::storage_type = const clang::FileEntry*]:
Assertion `!HasError && "Cannot get value when an error exists!"' failed.

[1]    827497 IOT instruction  clang-rename -offset=0 -new-name=plop asdasd

This fixes https://github.com/llvm/llvm-project/issues/36471.

Reviewed By: aaron.ballman

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

Depends on D146915

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

This commit doesn't replace `IntrinsicEmitter::ComputeFixedEncoding()`,
but compares outputs to it, to make sure implementation correct.

Depends on D145871, D145872, D145874, and D146914

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

They were dedicated to constant version of list slice.

Depends on D147401

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

This enables indexing in `!foreach` and permutation with `list[permlist]`.

Enhancements in syntax:

  - `list<int>` is applicable as a slice element.
  - `list[int,]` is evaluated as not `ElemType` but `list<ElemType>`
    with a single element.

Part of D145872

FIXME: I didn't apply new semantics to BitSlice.

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

There are no VOP2 or VOP2 with dpp forms of v_cndmask_b16. Delete the
test. NFC.

Reviewed By: critson

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

Not using cached constants when importing instructions may lead to
undesired results, as breaking dominance rules in the translated MLIR
module.

Signed-off-by: Victor Perez <victor.perez@codeplay.com>

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

The offset values may result in an erroneous scheduling of a load before write for a memory location if the offset values are represented as negative values in MIR, despite actually being unsigned values. This representation in MIR happens as SelectionDAG::getConstant could go through APInt to represent the encoding which assumes the MSB of the encoding as a sign-bit, regardless of whether it is supposed to be a signed value. The 8-bit negative (interpreted) value gets cast to an unsigned 32 bit value in getMemOperandsWithOffset used for comparisons in areMemAccessesTriviallyDisjoint eventually leading to an erroneous schedule in the machine scheduler.

Reviewed By: arsenm, foad

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

The prototype checker alpha.security.ArrayBoundV2 performs two
comparisons to check that in an expression like Array[Index]
    0 <= Index < length(Array)
holds. These comparisons are handled by almost identical logic: the
inequality is first rearranged by getSimplifiedOffsets(), then evaluated
with evalBinOpNN().

However the simplification used "naive" elementary mathematical
schematics, but evalBinOpNN() performed the signed -> unsigned
conversions described in the C/C++ standards, and this confusion led to
wildly inaccurate results: false positives from the lower bound check
and false negatives from the upper bound check.

This commit eliminates the code duplication by moving the comparison
logic into a separate function, then adds an explicit check to this
unified code path, which handles the problematic case separately.

In addition to this, the commit also cleans up a testcase that was
demonstrating the presence of this problem. Note that while that
testcase was failing with an overflow error, its actual problem was in
the underflow handler logic:
(0) The testcase introduces a five-element array "char a[5]" and an
    unknown argument "size_t len"; then evaluates "a[len+1]".
(1) The underflow check tries to determine whether "len+1 < 0" holds.
(2) This inequality is rearranged to "len < -1".
(3) evalBinOpNN() evaluates this with the schematics of C/C++ and
    converts -1 to the size_t value SIZE_MAX.
(4) The engine concludes that len == SIZE_MAX, because otherwise we'd
    have an underflow here.
(5) The overflow check tries to determine whether "len+1 >= 5".
(6) This inequality is rearranged to "len >= 4".
(7) The engine substitutes len == SIZE_MAX and reports that we have
    an overflow.

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

A cast from DIExpression->DIExpression is not needed.

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

This patch allows to specify that some part of tasks should be
done in sequential order. It makes it possible to not use
condition operator for separating sequential tasks:

TaskGroup tg;
for () {
  if(condition)      ==>   tg.spawn([](){fn();}, condition)
    fn();
  else
    tg.spawn([](){fn();});
}

It also prevents execution on main thread. Which allows adding
checks for getThreadIndex() function discussed in D142318.

The patch also replaces std::stack with std::deque in the
ThreadPoolExecutor to have natural execution order in case
(parallel::strategy.ThreadsRequested == 1).

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

This commit simplifies the text of DW_OP_LLVM_entry_value by making it
terser, replacing a verbose example with a more concrete one, providing
an explicit conclusion on the meaning of N=1, and by transforming the
description of which passes generate this op into a list (which enables
future expansion of this list).

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