The lowering bridge stores the evvironment defaults (passed to the
constructor) as a reference. In the call to the constructor in bbc, the
defaults were passed as `{}`, which creates a temporary whose lifetime
ends immediately after the call.
The flang driver passes a member of the compilation instance to the
constructor, which presumably remains alive long enough, so storing the
reference in the bridge is justified. To avoid the dangling reference,
create an actual object `envDefaults` in bbc.
Remove all the code that set and tested Res. Change all convert*
functions to return void since none of them can fail. getInstruction
only has one main point of failure, after all calls to tryDecodeInst
have failed.
The base case of these call InferPtrInfo. This is dangerous due to
#82657, but it turns out none of these are used.
It seemed best to reduce the surface area until these are needed.
Summary:
The GPU target has recently been changed to support standard `libc`
build rules. This means we should be able to build for it both in
`LLVM_ENABLE_PROJECTS` mode, or targeting the runtimes directory
directly as in the LLVM `libc` documentation. Previously this failed
because the version check on the compiler was too strict and the
`--target=` options were not being set on the link jobs unless in CMake
cross compiliation mode. This patch fixes those so the following config
should work now to build the GPU target directly if using NVPTX.
```
cmake ../runtimes -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang \
-DLLVM_ENABLE_RUNTIMES=libc -DLLVM_RUNTIMES_TARGET=nvptx64-nvidia-cuda \
-DLLVM_DEFAULT_TARGET_TRIPLE=nvptx64-nvidia-cuda \
-DLIBC_HDRGEN_EXE=/path/to/hdrgen/libc-hdrgen \
-DLLVM_LIBC_FULL_BUILD=ON -GNinja
```
Summary:
The AMDGPU target needs an external clock symbol so the driver can set
the frequency with the correct value. This was left over from the
previous implementation and I forgot to remove it when actually
implementing the timing utilities.
This is a follow-up to #82333. It is possible that the target block of a
`BlockTypeConversionRewrite` is detached, so the `MLIRContext` cannot be
taken from the block.
Target::SetArchitecture() does not necessarily set the triple that is
being passed in, and will unconditionally log the real architecture to
the log channel. By flipping the order between the log outputs, the
resulting combined log makes a lot more sense to read.
All SchedModel files have a line that looks like:
```
def SomeModel : SchedMachineModel;
let SchedModel = SomeModel in {
...
}
```
TableGen requires that all records defined within the top level `let`
must have a field `SchedModel` somewhere in their nested record
hierarchy (i.e. the record has a field `SchedModel : SchedMachineModel`
or recursively, one of its members has a field `SchedModel :
SchedMachineModel`).
Classes such as `SchedPredicate` have added a field `SchedModel :
SchedMachineModel`, even though the field is never used, just to supress
**errors** (not warnings) caused from having the top level let in the
model files. This decision was made to avoid having hundreds of the same
`let` statement littered in every scheduler model file.
The reason we have never seen an error for `SchedVar` before is because
`SchedVar` is never instantiated with a `def`. Instead, it is only
created as a value that is consumed by `SchedWriteVariant`:
```
... : SchedWriteVariant<[SchedVar<...>, SchedVar<...>]>;
```
There is a problem with this style of instantiation. In particular, the
problem arises as we try to take a class based approach to building
scheduler models. I will describe the problem from the bottom up.
The `LMULWriteResMXVariant` multiclass takes in a `SchedPredicateBase
Pred`. Today, the RISCVSchedSiFive7.td file defines `VLDSX0Pred` outside
the scope of any class. That means that `VLDSX0Pred` exists before
`LMULWriteResMXVariant` multiclass is instantiated. With this approach,
there is no error since the predicate is instantated in entirety before
the variant multiclass is instantiated. However, I have the intention to
move the definition of both the predicate and the variant multiclass
records inside a multiclass to factor out common parts between multiple
scheduler models.
I plan to have something like:
```
multiclass SiFive7Base<SiFive7BaseConfig c> {
def VLDSX0Pred : ...;
// Need defvar since record is prefixed with NAME.
defvar VLDSX0Pred = !cast<...>(NAME # VLDSX0Pred);
defm SiFive7 : LMULWriteResMXVariant<VLDSX0Pred>;
}
defm "SiFive7Version1" : SiFive7Base<SiFive7BaseConfig<...>>;
defm "SiFive7Version2" : SiFive7Base<SiFive7BaseConfig<...>>;
```
In this scheme, VLDSX0Pred is defined within the same multiclass
transaction that the `LMULWriteResMXVariant` is defined in. For some
reason, TableGen does not allow `Values` to reference records that were
created in the same parent record construction. If the `SchedVar` is not
a `def`, then it will not be able to find the record `NAME #
VLDSX0Pred`. Making it a def, allows TableGen to find `NAME #
VLDSX0Pred` in scope.
The simplest example of this is:
```
class A {}
class B<A a> { A x = a;}
class C<B b> { B y = b;}
multiclass D {
def MyA : A;
defvar aa = !cast<A>(NAME # MyA);
// This works
def : B<aa>;
// This does not work because constructing B by value cannot find `NAME # MyA`
// error: Undefined reference to record: 'MyA'
def : C<B<aa>>;
// To fix it, define it like such:
def MyB : B<aa>;
defvar bb = !cast<B>(NAME # MyB);
def : C<bb>;
}
defm "" : D;
```
In summary, in order to use a class based approach to creating scheduler
resources to promote resusability, `SchedVar`s must be created using
defs instead of being instantiated by value so that it can resolve
records that were part of the instantiation of the parent record being
created. In order to do this without refactoring the top level `let`
statement that all scheduler model files use, we add an unused field
`SchedModel : SchedMachineModel` to `SchedVar`, similiar to what has
been done in `SchedPredicate`.
Like linux releases, export a tar.xz files containing most llvm tools,
including non toolchain utilities, llvm-config, llvm-link and others.
We do this by reconfiguring cmake one last time at the last step,
running the install target so we do not need to recompile anything.
Fix#51192Fix#53052
Summary:
This block of code is used to prevent a GPU-based cross compiling build
from taking incompatible arguments. However this incorrectly used the
LLVM default triple instead of the runtimes target. Fix that so the bots
can continue to default the triple to NVPTX.
This commit fixes memory leaks that were introduced by #81759. The way
ops and blocks are erased changed slightly.
The leaks were caused by an incorrect implementation of op builders:
blocks must be created with the supplied builder object. Otherwise, they
are not properly tracked by the dialect conversion and can leak during
rollback.
This patch extends `propagatesPoison` to handle more integer intrinsics.
It will turn more logical ands/ors into bitwise ands/ors.
See also https://reviews.llvm.org/D99671.
When reconstructing lines from a macro expansion, make sure that lines
at different levels in the expanded code get indented correctly as part
of the macro argument.
These patterns can already be used via
populateMathPolynomialApproximationPatterns, but that includes a number
of other patterns that may not be needed.
There are already similar functions for expansion.
For now only adding tanh and erf since I have a concrete use case for
these two.
The below culprit patch enabled the generation of asynchronous unwind
tables (-funwind-tables=2) by default for RISCV for both linux and
RISCVToolChain baremetal object. However, since there are 2 baremetal
toolchain objects for RISCV, this created a discrepancy between their
behavior. Moreover, enabling the generation of asynchronous unwind
tables based on whether `-gcc-toolchain` option is present or not
doesn't seem to be the best criteria to decide on the same. This patch
make the behavior consistent by disabling the unwind tables in
RISCVToolChain Baremetal object.
Culprit Patch - https://reviews.llvm.org/D145164
`%ld` specifier is defined to work on values of type `long`. The parameter given to `fprintf` is of type `intptr_t` whose actual underlying integer type is unspecified. On Unix systems it happens to commonly be `long` but on 64-bit Windows it is defined as `long long`.
The cross-platform way to print a `intptr_t` is to use `PRIdPTR` which expands to the correct format specifier for `intptr_t`. This avoids any undefined behaviour and compiler warnings.
Patch 2 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds the DPLabel class, which is the RemoveDIs llvm.dbg.label
equivalent.
1. Add DbgRecord base class for DPValue and the not-yet-added
DPLabel class.
2. Add the DPLabel class.
-> 3. Add support to passes.
The next patch, #82639, will enable conversion between dbg.labels and DPLabels.
AssignemntTrackingAnalysis support could have gone two ways:
1. Have the analysis store a DPLabel representation in its results -
SelectionDAGBuilder reads the analysis results and ignores all DbgRecord
kinds.
2. Ignore DPLabels in the analysis - SelectionDAGBuilder reads the analysis
results but still needs to iterate over DPLabels from the IR.
I went with option 2 because it's less work and is no less correct than 1. It's
worth noting that causes labels to sink to the bottom of packs of debug records.
e.g., [value, label, value] becomes [value, value, label]. This shouldn't be a
problem because labels and variable locations don't have an ordering requirement.
The ordering between variable locations is maintained and the label movement is
deterministic
We previously defined svzero_za as:
void svzero_za();
rather than:
void svzero_za(void);
Which meant that Clang accepted arguments. Compiling for example
`svzero_za(<non-constant integer>)` ended up with incorrect IR and a
compiler crash because it couldn't select an instruction for it.
Despite of a valid tail call opportunity, backends still may not
generate a tail call or such lowering is not implemented yet.
Check that lowering has happened instead of its possibility when
generating G_ASSERT_ALIGN.
`ConversionPatternRewriterImpl` no longer maintains a reference to the
respective `ConversionPatternRewriter`. An `MLIRContext` is sufficient.
This commit simplifies the internal state of
`ConversionPatternRewriterImpl`.
The checker reported a false positive on this code
void testTaintedSanitizedVLASize(void) {
int x;
scanf("%d", &x);
if (x<1)
return;
int vla[x]; // no-warning
}
After the fix, the checker only emits tainted warning if the vla size is
coming from a tainted source and it cannot prove that it is positive.
Update include-cleaner tests. Now that we have proper found-decls set up
for VarTemplates, in case of instationtations we point to primary
templates and not specializations. To be changed in a follow-up patch.
This commit adds a new `ConversionConfig` struct that allows users to
customize the dialect conversion. This configuration is similar to
`GreedyRewriteConfig` for the greedy pattern rewrite driver.
A few existing options are moved to this objects, simplifying the
dialect conversion API.
