Bugs were found by Svace static analysis tool. Null pointers are
dereferenced right after error checking that does not return from
function.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D147706
This reduces dependencies on `llvm-tblgen` so much.
`CodeGenTypes` depends on `Support` at the moment.
Be careful to append deps on this, since Targets' tablegens
depend on this.
Depends on D149024
Differential Revision: https://reviews.llvm.org/D148769
This is rework of;
- rG13e77db2df94 (r328395; MVT)
Since `LowLevelType.h` has been restored to `CodeGen`, `MachinveValueType.h`
can be restored as well.
Depends on D148767
Differential Revision: https://reviews.llvm.org/D149024
This is rework of;
- D30046 (LLT)
Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen`
may depend on `CodeGen`.
`LowLevlType.h` originally belonged to `CodeGen`. Almost all userse are
still under `CodeGen` or `Target`. I think `CodeGen` is the right place
to put `LowLevelType.h`.
`MachineValueType.h` may be moved as well. (later, D149024)
I have made many modules depend on `CodeGen`. It is consistent but
inefficient. It will be split out later, D148769
Besides, I had to isolate MVT and LLT in modmap, since
`llvm::PredicateInfo` clashes between `TableGen/CodeGenSchedule.h`
and `Transforms/Utils/PredicateInfo.h`.
(I think better to introduce namespace llvm::TableGen)
Depends on D145937, D146352, and D148768.
Differential Revision: https://reviews.llvm.org/D148767
`llvm-min-tblgen` is capable of building `llvm/include/llvm`;
- `-gen-attrs`
- `-gen-directive-*`
- `-gen-intrinsics-*`
- `-gen-riscv-target-def`
`llvm-min-tblgen` is built and used only when `llvm-tblgen` is built in-tree.
This is not installed.
`llvm-tblgen` is built with complete set and may be installed.
`check-llvm` uses not `llvm-min-tblgen` but `llvm-tblgen`.
`LLVM_TABLEGEN_PROJECT` overrides the definition of `tablegen(project)`.
`LLVM_HEADERS` is used as the overridden prefix for LLVM header generators.
If `EXPORT` is not specified in `add_tablegen`, its tablegen is treated as internal.
Let `llvm-tblgen` depend on `intrinsics_gen`
Depends on D149072
Differential Revision: https://reviews.llvm.org/D146352
This is stricter than the default "ieee", and should probably be the
default. This patch leaves the default alone. I can change this in a
future patch.
There are non-reversible transforms I would like to perform which are
legal under IEEE denormal handling, but illegal with flushing zero
behavior. Namely, conversions between llvm.is.fpclass and fcmp with
zeroes.
Under "ieee" handling, it is legal to translate between
llvm.is.fpclass(x, fcZero) and fcmp x, 0.
Under "preserve-sign" handling, it is legal to translate between
llvm.is.fpclass(x, fcSubnormal|fcZero) and fcmp x, 0.
I would like to compile and distribute some math library functions in
a mode where it's callable from code with and without denormals
enabled, which requires not changing the compares with denormals or
zeroes.
If an IEEE function transforms an llvm.is.fpclass call into an fcmp 0,
it is no longer possible to call the function from code with denormals
enabled, or write an optimization to move the function into a denormal
flushing mode. For the original function, if x was a denormal, the
class would evaluate to false. If the function compiled with denormal
handling was converted to or called from a preserve-sign function, the
fcmp now evaluates to true.
This could also be of use for strictfp handling, where code may be
changing the denormal mode.
Alternative name could be "unknown".
Replaces the old AMDGPU custom inlining logic with more conservative
logic which tries to permit inlining for callees with dynamic handling
and avoids inlining other mismatched modes.
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
- Define `IIT_Info` in `Intrinsics.td`
- Implement `EmitIITInfo` in `IntrinsicEmitter.cpp`
- Use generated `IIT_Info` in `Function.cpp`
Depends on D145873 and D146179
Differential Revision: https://reviews.llvm.org/D146914
I don't think this code would work correctly if the register class
used used HwModes. Add asserts to make sure it's not used with HwModes.
Also fix a long outdated comment on the function.
Instead of copying elements to the NewOptionsToMatchVector, we
now shift down elements in OptionsToMatch as we create holes by
pulling out equal matchers. After we finish processing the vector,
we'll trim the size to just the elements that are still in use.
These vectors are resized in the constructor and never change size.
We can manually allocate two arrays instead.
This reduces the size of TreePatternNode by removing the
unneeded capacity end pointer fields from the std::vector.
There are some patterns in td files without MVT/class set
for some operands in target pattern that are from the source
pattern. This prevents GlobalISelEmitter from adding them as
a valid rule, because the target child operand is an
unsupported kind operand. For now, for a leaf child, only
IntInit and DefInit are handled in GlobalISelEmitter.
This issue can be workaround by adding MVT/class to the
patterns in the td files, like the workarounds for patterns
anyext and setcc in PPCInstrInfo.td in D140878.
To avoid adding the same workarounds for other patterns in
td files, this patch tries to handle the UnsetInit case in
GlobalISelEmitter.
Adding the new handling allows us to remove the workarounds
in the td files and also generates many selection rules for
PPC target.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D141247
We reserved 16 AddrSpaces in every TypeSetByHwMode. But we only ever
use the first one on targets that make use of the AddrSpace feature.
The vector was populated by pushing for each entry in the ArrayRef
passed to the TypeSetByHwMode constructor. Each entry is a
ValueTypeByHwMode that stores one VT for each HwMode.
The vector is accessed by a loop in TypeSetByHwMode::getValueTypeByHwMode.
That loop is over HwModes with in the TypeSetByHwMode. This is
unrelated to how the vector was created. The entries in the vector
don't represent HwModes.
The targets that use AddrSpace don't make use of HwModes so the
loop in getValueTypeByHwMode will only run 1 iteration. So we only
the first entry in the vector is meaningful used.
This patch simplifies things by storing only 1 AddrSpace in
TypeSetByMode. Reducing the memory used by TypeSetByHwMode.
More work will be needed to support HwModes with AddrSpace if we
need a different AddrSpace for each HwMode.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D148194
This patch replaces the uses of PointerUnion.is function by llvm::isa,
PointerUnion.get function by llvm::cast, and PointerUnion.dyn_cast by
llvm::dyn_cast_if_present. This is according to the FIXME in
the definition of the class PointerUnion.
This patch does not remove them as they are being used in other
subprojects.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D148449
An intrusive reference counter uses less memory than the control
block of std::shared_ptr.
This should allow some additional code simplifications if we
don't need to pass around shared_ptr in order to create new
shared_ptrs.
- Implement `VTEmitter` as `llvm-tblgen -gen-vt`.
- Create a copy of `llvm/Support/MachineValueType.h` into `unittests/Support`.
It includes `GenVT.inc` generated by `VTEmitter`.
- Implement `MVTTest` in `SupportTests`. It checks equivalence between
`llvm/Support/MachineValueType.h` and the generated header.
Differential Revision: https://reviews.llvm.org/D146906
Instead of storing a string containing the instruction name, store a
reference to the instruction. We can use that reference to print the
instruction name when we emit the table.
The only slightly annoying part is that we have to find the
CodeGenInstruction for IMPLICIT_DEF. GlobalISel is doing
a similar thing.
