Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(with cPTR and cN being the capability equivalents of iPTR and iN).
Moreover, iPTRAny is already not itself regarded as an integer (calling
isInteger() will give false), so the "i" prefix is misleading, and it
stands out as different from all the other xAny that have a single
letter prefix denoting their type.
Thus, rename it to pAny, reflecting that it is an overloaded pointer
type, which could end up being specialised to an integer type, but does
not have to be.
This has been verified to have no effect on the generated files for LLVM
itself or any in-tree target beyond the replacement of the identifier
iPTRAny with pAny in GenVT.inc.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113733
We've already called EnforceInteger on Types[0], and iPTRAny isn't
regarded as an integer type (note that TableGen special-cases iPTR here
to include that, though), so we cannot possibly still have an iPTRAny by
this point. Delete the check, and let getFixedSizeInBits catch it along
with all the other overloaded types if that ever becomes false. Also
document why we have this check whilst here.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113732
The former is a wrapper for the latter with two differences: Other is
mapped to "UNKNOWN" (rather than "MVT::Other"), and iPTR(Any) are mapped
to "TLI.getPointerTy()" rather than "MVT::iPTR(Any)".
The only uses are in FastISelMap::printFunctionDefinitions. Most of
these uses are just a form of name mangling to ensure uniqueness, so the
actual string isn't important (and, in the case of MVT::iPTR(Any), were
both to be used, they would clash). Two uses are for a case statement,
which requires the expression to be a constant (of the right type), but
neither UNKNOWN nor TLI.getPointerTy() are constants, so would not work
there. The remaining uses are where an expression is needed, so UNKNOWN
similarly doesn't work, though TLI.getPointerTy() could in this case.
However, neither iPTR nor iPTRAny are supposed to make it this far
through TableGen, and should instead have been replaced with concrete
types, so this case should not be hit. Moreover, for almost all of these
uses, the name is passed to getLegalCName, which will strip an MVT::
prefix but will leave TLI.getPointerTy() unchanged, which is not a valid
C identifier, nor component thereof.
Thus, delete this unnecessary, and mostly-broken, wrapper and just use
the underlying getEnumName. This has been verified to have no effect on
the generated files for any in-tree target, including experimental ones.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113731
Code cleanups for TableGen files, changes includes function names,
variable names and unused imports.
---------
Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>
fixes#112974
partially fixes#70103
### Changes
- Added new tablegen based way of lowering dx intrinsics to DXIL ops.
- Added int_dx_group_memory_barrier_with_group_sync intrinsic in
IntrinsicsDirectX.td
- Added expansion for int_dx_group_memory_barrier_with_group_sync in
DXILIntrinsicExpansion.cpp`
- Added DXIL backend test case
### Related PRs
* [[clang][HLSL] Add GroupMemoryBarrierWithGroupSync intrinsic
#111883](https://github.com/llvm/llvm-project/pull/111883)
* [[SPIRV] Add GroupMemoryBarrierWithGroupSync intrinsic
#111888](https://github.com/llvm/llvm-project/pull/111888)
`NumDefs` only counts the number of registers in `(outs)`, not any
implicit defs specified with `Defs = [...]`
This causes patterns with physical register defs to fail to import here
instead of later where implicit defs are rendered.
Add on `ImplicitDefs.size()` to count both and create `DstExpDefs` to
count only explicit defs, used later on.
Check name conflicts between intrinsics caused by mangling suffix.
If the base name of an overloaded intrinsic is a proper prefix of
another intrinsic, check if the other intrinsic name suffix after the
proper prefix can match a mangled type and issue an error if it can.
Add support for taking the intersection of two AttributeLists s.t the
result list contains attributes that are valid in the context of both
inputs.
i.e if we have `nonnull align(32) noundef` intersected with `nonnull
align(16) dereferenceable(10)`, the result is `nonnull align(16)`.
Further it handles attributes that are not-droppable. For example
dropping `byval` can change the nature of a callsite/function so its
impossible to correct a correct intersection if its dropped from the
result. i.e `nonnull byval(i64)` intersected with `nonnull` is
invalid.
The motivation for the infrastructure is to enable sinking/hoisting
callsites with differing attributes.
Decrease code size of `Intrinsic::getAttributes` function by uniquing
the function and argument attributes separately and using the
`IntrinsicsToAttributesMap` to store argument attribute ID in low 8 bits
and function attribute ID in upper 8 bits.
This reduces the number of cases to handle in the generated switch from
368 to 131, which is ~2.8x reduction in the number of switch cases.
Also eliminate the fixed size array `AS` and `NumAttrs` variable, and
instead call `AttributeList::get` directly from each case, with an
inline array of the <index, AttribueSet> pairs.
Currently, type casts can only be used to pattern match for intrinsics
with a single overloaded return value. For instance:
```
def int_foo : Intrinsic<[llvm_anyint_ty], []>;
def : Pat<(i32 (int_foo)), ...>;
```
This patch extends type casts to support matching intrinsics with
multiple overloaded return values. As an example, the following defines
a pattern that matches only if the overloaded intrinsic call returns an
`i16` for the first result and an `i32` for the second result:
```
def int_bar : Intrinsic<[llvm_anyint_ty, llvm_anyint_ty], []>;
def : Pat<([i16, i32] (int_bar)), ...>;
```
Validate that for target independent intrinsics the second dotted
component of their name (after the `llvm.`) does not match any existing
target names (for which atleast one intrinsic has been defined). Doing
so is invalid as LLVM will search for that intrinsic in that target's
intrinsic table and not find it, and conclude that its an unknown
intrinsic.
Intrinisc type signature is a `list<list<int>>` that hold IIT encoding
for each param/ret type (outer list) where the IIT encoding for each
type itself can be 0 or more integers (the inner list). Intrinsic
emitter flatten this list into generate the type signature in
`ComputeTypeSignature`.
Use the new !listflatten() operator to instead flatten the list in the
TableGen definition and eliminate flattening in the emitter code.
Verified that `-gen-intrinsic-impl` output for Intrinsics.td is
identical with and without the change.
Adopt scaled indent in PredicateExpander.
Added pre/post inc/dec operators to `indent` and related unit tests.
Verified by comparing *.inc files generated by LLVM build with/without
the change.
Update llvm's TableGen to emit new explicit symbol visibility macros I
added in https://github.com/llvm/llvm-project/pull/96630 to the function
declarations it creates
The generated functions need to be exported from llvm's shared library
for Clang and some OpenMP tests. @compnerd
Speed up sorting of intrinsics by using the TargetPrefix to only
discriminate beteween target dependent vs target independent intrinsics
where target independent ones need to be sorted before target dependent
ones. When comparing two target dependent intrinsics, the Name already
includes `llvm.<TargetPrefix>` as a prefix, so no need to needlessly
compare it separately.
It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.
