Most forks won't have an LLVM_BUGS_KEY secret, so Mailgun will error out
with a missing key, and if forks do happen to have such a secret then we
still don't want to be getting emails to LLVM's mailing lists for
downstream forks.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D146235
d4320cb2a5 fixed a regular build
issue by making the flang tests depend on llvm-readelf.
Turns out llvm-readelf is a symlink to llvm-readobj and for
whatever reason, doesn't have the right exports at the moment
to be picked up in a standalone build.
https://lab.llvm.org/buildbot/#/builders/175/builds/26448
Maybe we should fix that, but for now, just require llvm-readobj
instead.
Just use conversion from assuemd type to assumed type
because a rebox needs more information that are not available
with assumed type.
Also use `isAssumedType` instead of `isBoxNone` since assumed
type can have sequence information.
Depends on D146207
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D146209
When passing an argument to an assumed type dummy argument, embox
it directly to a !fir.box<none> box.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D146207
The loop vectorizer supports generating interleaved loads and stores via
shuffle patterns for fixed length vectors.
This enables it for RISC-V, since interleaved shuffle patterns can be
lowered to vlseg/vsseg in https://reviews.llvm.org/D145022
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D145155
Consider a shuffle mask of <0, 2>:
This is one of two deinterleave masks to deinterleave a vector of 4
elements with factor 2.
Unfortunately, this is also technically an interleave mask, where
two subvectors of length 1 at indexes 0 and 2 will be interleaved.
This is because a mask can interleave non-contiguous subvectors:
e.g. <0, 6, 4, 1, 7, 5> on a vector of size 8:
```
<0 1 2 3 4 5 6 7> indices
^ ^ ^ ^ ^ ^
0 0 2 2 1 1 deinterleaved subvector
```
This means that deinterleaving shuffles can accidentally be costed as
interleaves.
And it's incorrect in the context of interleaves, because the
only interleave shuffles we model at the moment are single permutation
shuffles, i.e. we are interleaving the first vector below and ignoring
the second:
shufflevector <2 x i32> %v0, <2 x i32> poison, <2 x i32> <i32 0, i32 2>
A mask of <0, 2> interleaves across both vectors.
The fix here is to set NumInputElts correctly: We were setting it to
twice the mask length, i.e. using both input vectors. But in fact we're
actually only using the first vector here, and isInterleaveMask actually
already has logic to ensure that the mask indices stay within the bounds
of the input vectors.
This lacks a test case due to how we're unable to test deinterleave
shuffles (because they are length changing), but is covered in the tests
in D145155
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D146176
When applying vector masking we may create a mask and then transpose it.
Transpositions are extremely expensive so this patch introduces a new
canonicalization pattern that remove the tranpose operation and create a
new transposed mask.
Differential Revision: https://reviews.llvm.org/D146193
Currently the `getTiledImplementation` and `generateResultTileValue`
return just `SmallVector<Operation *>` and `FailureOr<Value>`.
- For `getTiledImplementation` returning empty implies tiling wasnt
done. There is also an implicit assumption that the tiled operation
results correspond to the tiled values of the result of the original
operation. This cannot handle cases where the tiled implementation
might use multiple operations to compute the tiled value for the
results of the untiled operation. Sometimes, the tiled operation
might not directly give the tiled values, and might require casts,
etc to get a replacement.
- For `generateResultTileValue`, it is assumed that the op defining
the returned `Value` is the operation that represents the tiled
computation. Again presence of casts, etc violate this.
Instead make these methods return
```
struct TilingResult {
SmallVector<Operation *> tiledOps;
SmallVector<Value> tiledValues;
};
```
The `tiledOps` represent the operations generated that are relevant
for subsequent transformations. The `tiledValues` represent the tiled
values for the results of the original operation. This better
transmits the state of the transformed IR.
As a consequence the following methods also return `FailureOr<TilingResult>`
- `tensor::replaceExtractSliceWithTiledProducer`
- `tensor::bubbleUpPadSlice`
Differential Revision: https://reviews.llvm.org/D145133
This is a mitigation patch for
https://bugs.chromium.org/p/llvm/issues/detail?id=30, where existing stack
protection is skipped if a function is returned through by an unwinder rather
than the normal call/return path. The recent patch D139254 added the ability to
instrument a visible unwind path, at least in the IR case (I'm working on the
SelectionDAG instrumentation too) but there are still invisible unwinds it
can't reach.
So this patch adds logic to DwarfEHPrepare that goes through a function,
converting any call that might throw into an invoke to a simple resume cleanup,
and adding cleanup clauses to existing landingpads that lack them. Obviously we
don't really want to do this if it's wasted effort, so I also exposed
requiresStackProtector from the actual StackProtector code to skip the extra
paths if they won't be used.
Changes:
* Move test to AArch64 directory as it relies on target presence.
* Re-add Dominator-tree maintenance. Accidentally cherry-picked wrong patch.
* Skip adding paths on Windows EH functions.
https://reviews.llvm.org/D143637
tosa.reshape and tosa.concat were moved from TosaToLinalg to TosaToTensor
(D145119 & D145952). So now they are legal after applying TosaToLinalg patterns,
and illegal after applying TosaToTensor patterns.
This includes D146174 (thanks @ramiro050!)
Reviewed By: krzysz00
Differential Revision: https://reviews.llvm.org/D146213
Summary:
The changes in D146184 made the integration tests use the inhereted
dependencies from the startup code like a normal target. For the AArch64
target this resulted in the threads depenency not being pulled in
because it was not present in the original code.
All integration tests rely on the startup code to be run. Currently we
manually include a few of these dependencies that are relevant for the
Linux target. This patch changes this to make the integration test's
dependencies include all the dependencies of the startup code. This
simplifies the code and makes it easier to support different targets.
The changes here cause the integration test to be dependent on more
targets than previously necessary, but it should be fine.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D146184
TemplateName::getAsTemplateDecl() returns the underlying TemplateDecl
for a UsingTemplate kind template name. We should respect that in the
Profile method otherwise we might desugar the template name unexpectedly
(e.g. for template argument deduction with deduciton guides).
Differential Revision: https://reviews.llvm.org/D146202
This is a mitigation patch for
https://bugs.chromium.org/p/llvm/issues/detail?id=30, where existing stack
protection is skipped if a function is returned through by an unwinder rather
than the normal call/return path. The recent patch D139254 added the ability to
instrument a visible unwind path, at least in the IR case (I'm working on the
SelectionDAG instrumentation too) but there are still invisible unwinds it
can't reach.
So this patch adds logic to DwarfEHPrepare that goes through a function,
converting any call that might throw into an invoke to a simple resume cleanup,
and adding cleanup clauses to existing landingpads that lack them. Obviously we
don't really want to do this if it's wasted effort, so I also exposed
requiresStackProtector from the actual StackProtector code to skip the extra
paths if they won't be used.
https://reviews.llvm.org/D143637
1. Align ManualMapSet with X86MemoryFoldTableEntry instead of using UnfoldStrategy
2. ManualMapSet able to update the existing record in auto-generated MemFold table
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D142084
This follows 2b4fa53 which made Clang not emit destructor calls for such
objects. However, they would still not get emitted as constants since
CodeGenModule::isTypeConstant() returns false if the destructor is
constexpr. This change adds a param to make isTypeConstant() ignore the
dtor, allowing the caller to check it instead.
Fixes Issue #61212
Differential revision: https://reviews.llvm.org/D145369
Allow the value-component of a dbg.assign to be salvaged using a variadic
DIExpression.
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D145915
Use RawLocationWrapper rather than a Value to represent the location operand(s)
so that it's possible to represent multiple location
operands. AssignmentTrackingAnalysis still converts variadic debug intrinsics
to kill locations so this patch is NFC.
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D145911
RawLocationWrapper wraps the location operand of a debug intrinsic which may be
either (wrapped in MetadataAsValue) a DIArgList, ValueAsMetadata, or an empty
MDTuple. This class lets us avoid duplicating location handling code in a later
patch in this stack.
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D145909
