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

The patch prevents pollution of instruction comments with error messages
generated during unsuccessful decoding attempts.

Reviewed By: foad

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

Replacement for D144903

If we're concatenating freeze(undef) subvector ops with multiple uses then we can't treat them as a wider freeze(undef), but we can replace them with a zero subvector, which is cheap on AVX

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

Test for https://github.com/llvm/llvm-project/issues/62380/.

These two tests were created from little snippets added late
in the review of the loop versioning work. The code was fixed
to cope with the situation and correctly compile these samples.

This adds tests to avoid regressions in this area.

Reviewed By: tblah

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

This patch improves the diagnostics of the alpha.security.taint.TaintPropagation
checker and taint related checkers by showing the "Taint originated here" note
at the correct place, where the attacker may inject it. This greatly improves
the understandability of the taint reports.

In the baseline the taint source was pointing to an invalid location, typically
somewhere between the real taint source and sink.

After the fix, the "Taint originated here" tag is correctly shown at the taint
source. This is the function call where the attacker can inject a malicious data
(e.g. reading from environment variable, reading from file, reading from
standard input etc.).

This patch removes the BugVisitor from the implementation and replaces it with 2
new NoteTags. One, in the taintOriginTrackerTag() prints the "taint originated
here" Note and the other in taintPropagationExplainerTag() explaining how the
taintedness is propagating from argument to argument or to the return value
("Taint propagated to the Xth argument"). This implementation uses the
interestingess BugReport utility to track back the tainted symbols through
propagating function calls to the point where the taintedness was introduced by
a source function call.

The checker which wishes to emit a Taint related diagnostic must use the
categories::TaintedData BugType category and must mark the tainted symbols as
interesting. Then the TaintPropagationChecker will automatically generate the
"Taint originated here" and the "Taint propagated to..." diagnostic notes.

Remove assert from AssignmentTrackingAnalysis that fires if a local variable
has non-alloca storage. The analysis can emit these locations but the
assignment tracking code in SelectionDAG isn't ready to handle non-alloca
storage for locals yet. The AssignmentTrackingPass (pass that adds assignment
tracking metadata) ignores non-alloca dbg.declares, so the only variables
affected are those who's backing storage is changed from an alloca during
optimisation, and the result is the variables are dropped.

Fixes: https://ci.chromium.org/ui/p/pigweed/builders/toolchain/
                 toolchain-ci-pigweed-linux/b8783274592206481489/overview

Reviewed By: StephenTozer

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

I barely understand what this does, but try to
handle the last case required to delete cannotBeOrderedLessThanZeroImpl.
Also improve by following fdiv handling for nans and identical operand case.

It's currently broken

Copy what cannotBeOrderedLessThanZeroImpl checks for fdiv.

The vectors being sorted here shouldn't contain duplicate entries. Prior to
this patch this was checked with an assert within the `std::sort`
predicate. However, `std::sort` may compare an element against itself which
causes the assert to fire (false positive). Move the assert outside of the sort
predicate to avoid such issues.

Reviewed By: StephenTozer

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

The logic enabling the Arm SVE (and now SME) integration tests for
various dialects, that may run under emulation, is now duplicated in
several places.

This patch moves the configuration to the top-level MLIR integration
tests Lit config and renames the '%lli' substitution in contexts where
it will run exclusively (ArmSVE, ArmSME) on AArch64 (and possibly under
emulation) to '%lli_aarch64_cmd', and '%lli_host_or_aarch64_cmd' for
contexts where it may run AArch64 (also possibly under emulation). The
latter is for integration tests that have target-specific and
target-agnostic codepaths such as SparseTensor, which supports scalable
vectors.

The two substitutions have the same effect but the names are different to
convey this information. The '%lli_aarch64_cmd' substitution could be
used in the SparseTensor tests but that would be a misnomer if the host
were x86 and the MLIR_RUN_SVE_TESTS=OFF.

The reason for renaming the '%lli' substitution is to not prevent running other
target-specific integration tests at the same time, since the same substitution
'%lli' is used for lli in other integration tests:

  * mlir/test/Integration/Dialect/Vector/CPU/X86Vector              - (AVX emulation via Intel SDE)
  * mlir/test/Integration/Dialect/Vector/CPU/AMX                    - (AMX emulation via Intel SDE)
  * mlir/test/Integration/Dialect/LLVMIR/CPU/test-vp-intrinsic.mlir - (RISCV emulation via QEMU if supported, native otherwise)

and substituting '%lli' at the top-level with Arm specific logic would override
this.

Reviewed By: awarzynski

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

Commit a93c4239 broke docs buildbot:
https://lab.llvm.org/buildbot/#/builders/30/builds/34525

426db6b4 added the build_vector(undef,freeze(undef)) -> freeze(undef) fold, but failed to account for cases where the scalar freeze(undef) had multiple uses, in those cases we can only only safely fold to a zero vector

https://alive2.llvm.org/ce/z/87jG8K