| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(#175063)
This patch proposes new a tuning feature string format that helps users
to build a performance model by "configuring" an existing tune CPU,
along with its scheduling model. For example, this string
```
"sifive-x280:single-element-vec-fp64"
```
takes ``sifive-x280`` as the "base" tune CPU and configured it with
``single-element-vec-fp64``. This gives us a performance model that
looks exactly like that of ``sifive-x280``, except some of the 64-bit
vector floating point instructions now produce only a single element per
cycle due to ``single-element-vec-fp64``.
This string could eventually be used in places like ``-mtune`` at the
frontend. Right now, this patch only implements the parser part, which
is put under the TargetParser library.
The grammar for this string is:
```
tune-cpu ::= 'tuning CPU name in lower case'
directive ::= "[a-zA-Z0-9_-]+"
tune-features ::= directive ["," directive]*
```
A *directive* can and can only _enable_ or _disable_ a certain tuning
feature from the tuning CPU. A **positive directive**, like the
``single-element-vec-fp64`` we just saw, enables an additional tuning
feature in the associated tuning model.
A **negative directive**, on the other hand, removes a certain tuning
feature. For example, ``sifive-x390`` already has the
``single-element-vec-fp64`` feature, and we can use
"sifive-x390:no-single-element-vec-fp64" to create a new performance
model that looks nearly the same as ``sifive-x390`` except
``single-element-vec-fp64`` being cut out. In this case,
``no-single-element-vec-fp64`` is a negative directive.
There are additional restrictions on what we can put in the list of
directives, please refer to the documentations for more details.
Right now, this string only accepts directives that are explicitly
supported by the tune CPU. For example, "sifive-x280:prefer-w-inst" is
not a valide string as ``prefer-w-inst`` is not supported by
``sifive-x280`` at this moment. Vendors of these processors are expected
to maintain the compatibility of their supported directives across
different versions.
---------
Co-authored-by: Sam Elliott <aelliott@qti.qualcomm.com>
|
|
Remove the warning issued by intrinsic emitter when an entry in the
`IntrinsicsToAttributesMap` is > 16 bits. The exact conditions under
which this happen is tightly coupled with how the intrinsic emitter
represents intrinsic attributes and generally this warning may not be
actionable in any way without changing the semantics of the intrinsics
being compiled (i.e., changing their attributes to have less number of
unique attributes).
|
|
|
|
- Adopt IfDefEmitter in IntrinsicEmitter.
- Remove #undef for various flags in Intrinsics.cpp/Intrinsics.h as the
TableGen generated code does that now.
|
|
Change Intrinsics.cpp to rely on the type `FixedEncodingTy` emitted by
the intrinsic emitter in `getIntrinsicInfoTableEntries` to process the
intrinsic type table. This enables downstream targets that need a 32-bit
fixed encoding table to just change the value of `Use16BitFixedEncoding`
in the intrinsic emitter to enable 32-bit fixed encoding table.
|
|
Use `auto` for iterators, range for loop in `layout` and rename
`Entries` to a more canonical `Size`.
|
|
(#177161)
…unctions (#176253)"
This reverts commit cf68af690ba7f98943e5f0f5cb39a91868d62098.
It increased the compilation time for a number of clang source files.
See comments in https://github.com/llvm/llvm-project/pull/176253 for
more information.
|
|
Several of the functions that TableGen emits into the .cpp files for
OpenACC or OpenMP could be constexpr. They can't just be emitted into
the header files as constexpr as they are because they use "assert" and
"llvm_unreachable".
To preserve the existing functionality, this patch will cause TableGen
to emit the constexpr variants that return the value as std::optional,
where std::nullopt indicates an error. The exisiting functions will
invoke the constexpr versions and call assert/llvm_unreachable if
nullopt is returned. E.g.
```
// .h
constexpr std::optional<Association>
getDirectiveAssociationOpt(Directive D) {
switch (D) {
case ...:
return Association::Block;
...
} // switch (D)
return std::nullopt;
}
// .cpp
Association getDirectiveAssociation(Directive D) {
if (auto X = getDirectiveAssociationOpt(D)) {
return *X;
}
llvm_unreachable("Unexpected directive");
}
```
|
|
|
|
Implements https://github.com/ARM-software/acle/pull/404
This allows the user to specify "featA+featB;priority=[1-255]" where
priority=255 means highest priority. If the explicit priority string is
omitted then the priority of "featA+featB" is implied, which is lower
than priority=1.
Internally this gets expanded using special FMV features P0 ... P7 which
can encode up to 256-1 priority levels (excluding all zeros). Those do
not have corresponding detection bit at pos FEAT_#enum so I made this
field optional in FMVInfo. Also they don't affect the codegen or name
mangling of versioned functions.
|
|
Remove explicit VT numbers from ValueTypes.td so that patches that add a
new VT do not have to renumber the entire file.
In TableGen VTs are now identified by ValueType.LLVMName instead of
ValueType.Value. This is important for target-defined types (typically
based on PtrValueType) which are not mentioned in ValueTypes.td itself.
|
|
Identified with bugprone-unused-local-non-trivial-variable.
|
|
OpenMP 6.0 introduced a `fuse` directive, and with it a "loop sequence"
as the associated code. What used to be "loop association" has become
"loop-nest association".
Rename Association::Loop to LoopNest, add Association::LoopSeq to
represent the "loop sequence" association.
Change the association of fuse from "block" to "loop sequence".
|
|
The collection of library function names in TargetLibraryInfo faces
similar challenges as RuntimeLibCalls in the IR component. The number of
function names is large, there are numerous customizations based on the
triple (including alternate names), and there is a lot of replicated
data in the signature table.
The ultimate goal would be to capture all lbrary function related
information in a .td file. This PR brings the current .def file to
TableGen, almost as a 1:1 replacement. However, there are some
improvements which are not possible in the current implementation:
- the function names are now stored as a long string together with an
offset table.
- the table of signatures is now deduplicated, using an offset table for
access.
The size of the object file decreases about 34kB with these changes. The
hash table of all function names is still constructed dynamically. A
static table like for RuntimeLibCalls is the next logical step.
The main motivation for this change is that I have to add a large number
of custom names for z/OS (like in RuntimeLibCalls.td), and the current
infrastructur does not support this very well.
|
|
Always rely on local scopes to enforce the lifetime of these helper
objects and by extension where the "closing" of various C++ code
constructs happens.
|
|
It was switched from a function pointer to std::function in
TableGen: Make 2nd arg MainFn of TableGenMain(argv0, MainFn) optional.
f675ec6165ab6add5e57cd43a2e9fa1a9bc21d81
but there's no mention of any particular reason for that.
|
|
This patch introduces preliminary support for additional memory
locations.
They are: target_mem0 and target_mem1 and they model memory locations
that cannot be represented with existing memory locations.
It was a solution suggested in :
https://discourse.llvm.org/t/rfc-improving-fpmr-handling-for-fp8-intrinsics-in-llvm/86868/6
Currently, these locations are not yet target-specific. The goal is to
enable the compiler to express read/write effects on these resources.
|
|
This patch adds LLVM infrastructure to support pretty printing of the
intrinsic arguments.
The motivation is to improve the readability of LLVM intrinsics and
facilitate easy
modifications and debugging of LLVM IR.
This feature adds a property `ArgInfo<ArgIndex, [ArgName<"argName">,
ImmArgPrinter<"functionName">]>`
to the intrinsic arguments to print self-explanatory inline comments for
the arguments.
The addition of pretty print support can provide a simple, low-overhead
feature that
enhances the usability of LLVM intrinsics without disrupting existing
workflows.
Link to the RFC, where this feature was discussed:
https://discourse.llvm.org/t/rfc-pretty-printing-immediate-arguments-in-llvm-intrinsics/88536
---------
Signed-off-by: Dharuni R Acharya <dharunira@nvidia.com>
Co-authored-by: Rahul Joshi <rjoshi@nvidia.com>
|
|
Teach `SDNodeInfoEmitter` TableGen backend to process `SDTypeConstraint`
records and emit tables for them. The tables are used by
`SDNodeInfo::verifyNode()` to validate a node being created.
This PR only adds validation code for `SDTCisVT` and `SDTCVecEltisVT`
constraints to keep it smaller.
Pull Request: https://github.com/llvm/llvm-project/pull/150125
|
|
Reduces memory usage compiling backend sources, most notably for
AMDGPU by ~98 MB per source on average.
AMDGPUGenRegisterInfo.inc is tens of megabytes in size now, and
is even larger downstream. At the same time, it is included in
nearly all backend sources, typically just for a small portion of
its content, resulting in compilation being unnecessarily
memory-hungry, which in turn stresses buildbots and wastes their
resources.
Splitting .inc files also helps avoiding extra ccache misses
where changes in .td files don't cause changes in all parts of
what previously was a single .inc file.
It is thought that rather than building on top of the current
single-output-file design of TableGen, e.g., using `split-file`,
it would be more preferable to recognise the need for multi-file
outputs and give it a proper first-class support directly in
TableGen.
|
|
Identified with modernize-use-using.
|
|
This information will be needed in more emitters, so start factoring
it to be more reusable.
|
|
Introduce a new class for the TargetLowering usage. This tracks the
subtarget specific lowering decisions for which libcall to use.
RuntimeLibcallsInfo is a module level property, which may have multiple
implementations of a particular libcall available. This attempts to be
a minimum boilerplate patch to introduce the new concept.
In the future we should have a tablegen way of selecting which
implementations should be used for a subtarget. Currently we
do have some conflicting implementations added, it just happens
to work out that the default cases to prefer is alphabetically
first (plus some of these still are using manual overrides
in TargetLowering constructors).
|
|
|
|
Emit empty line after a namespace scope is opened and before its closed.
Adjust DirectiveEmitter code empty line emission in response to this to
avoid lot of unit test changes.
|
|
Also add a corresponding intrinsic property that can be used to mark
intrinsics that do not introduce poison, for example simple arithmetic
intrinsics that propagate poison just like a simple arithmetic
instruction.
As a smoke test this patch adds the new property to
llvm.amdgcn.fmul.legacy.
|
|
This patch removes const to allow std::move a couple of lines below to
perform a move operation as intended.
Identified with performance-move-const.
|
|
Identified with modernize-use-equals-default.
|
|
Print a note when the manually specified name in an intrinsic matches
the default name it would have been assigned based on the record name,
in which case the manual specification is redundant and can be
eliminated.
Also remove existing redundant manual names.
|
|
|
|
|
|
(#163283)
Add a RAII class `IncludeGuardEmitter` which is similar to
`IfDefEmitter` but emits header include guards and adopt it in
DirectiveEmitter.
|
|
The Unsupported case is special and doesn't have an entry in the
vector, and is directly emitted as the 0 case. This should be
harmless as it is, but could break if the right number of new
libcalls is added.
|
|
This is a step towards separating the set of available libcalls
from the lowering decision of which call to use. Libcall recognition
now directly checks availability instead of indirectly checking through
the lowering table.
|
|
This reverts 9c361cc and replaces f490dbdc. Instead of using the lambda
to try avoid naming the variables, just disambiguate the different
AlwaysAvailable
sets with the calling convention name.
|
|
This change resolves a stack usage issue seen in the TableGen'd function
`setTargetRuntimeLibcallSets` when compiled with MSVC. This change
reduces the frame size from 47720 bytes to 48 bytes.
|
|
RISC-V tuples use "NF" not "nElem" to store the number of fields in the
segment.
This fixes a crash when lowering a function with tuple return.
getReturnInfo in CallLowering.cpp does Type*->EVT->Type* and we were
incorrectly converting EVT to Type*.
|
|
|
|
|
|
values
- Currently, Intrinsic can only have up to 9 return values. In case new
intrinsics require more than 9 return values, additional ITT_STRUCTxxx
values need to be added to support > 9 return values. Instead, this
patch unifies them into a single IIT_STRUCT followed by a BYTE
specifying the minimal 2 (encoded as 0) and maximal 257 (encoded as
255) return values.
|
|
|
|
This is a minor fix from comment
https://github.com/llvm/llvm-project/pull/157965/files#r2347317186
introduced in #157965.
|
|
Make IntrinsicsToAttributesMap's func. and arg. fields be able to have
adaptive sizes based on input other than hardcoded 8bits/8bits.
This will ease the pressure for adding new intrinsics in private
downstreams.
func. attr bitsize will become 7(127/128) vs 8(255/256)
|
|
This adds value types for representing capability types, enabling their use in instruction selection and other parts of the backend.
These types are distinguished from each other only by size. This is sufficient, at least today, because no existing CHERI configuration supports multiple capability sizes simultaneously. Hybrid configurations supporting intermixed integral pointers and capabilities do exist, and are one of the reasons why these value types are needed beyond existing integral types.
Co-authored-by: David Chisnall <theraven@theravensnest.org>
Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com>
|
|
|
|
As noted in #153256, TableGen is generating reserved names for
RuntimeLibcalls, which resulted in a build failure for Arm64EC since
`vcruntime.h` defines `__security_check_cookie` as a macro.
To avoid using reserved names, all impl names will now be prefixed with
`Impl_`.
`NumLibcallImpls` was lifted out as a `constexpr size_t` instead of
being an enum field.
While I was churning the dependent code, I also removed the TODO to move
the impl enum into its own namespace and use an `enum class`: I
experimented with using an `enum class` and adding a namespace, but we
decided it was too verbose so it was dropped.
|
|
We were sizing the table appropriately for the number of LibcallImpls,
but many of those have identical names which were pushing up the
collision count unnecessarily. This ends up decreasing the table size
slightly, and makes it a bit faster.
BM_LookupRuntimeLibcallByNameRandomCalls improves by ~25% and
BM_LookupRuntimeLibcallByNameSampleData by ~5%.
As a secondary change, align the table size up to the next
power of 2. This makes the table larger than before, but improves
the sample data benchmark by an additional 5%.
|
|
Also starts pruning out these calls if the exception model is
forced to none.
I worked backwards from the logic in addPassesToHandleExceptions
and the pass content. There appears to be some tolerance
for mixing and matching exception modes inside of a single module.
As far as I can tell _Unwind_CallPersonality is only relevant for
wasm, so just add it there.
As usual, the arm64ec case makes things difficult and is
missing test coverage. The set of calls in list form is necessary
to use foreach for the duplication, but in every other context a
dag is more convenient. You cannot use foreach over a dag, and I
haven't found a way to flatten a dag into a list.
This removes the last manual setLibcallImpl call in generic code.
|
|
(#153864)
This reverts commit 334e9bf2dd01fbbfe785624c0de477b725cde6f2.
Check if llvm-nm exists before building the benchmark.
|
|
(#153864)
…210)"
This reverts commit 9a14b1d254a43dc0d4445c3ffa3d393bca007ba3.
Revert "RuntimeLibcalls: Return StringRef for libcall names (#153209)"
This reverts commit cb1228fbd535b8f9fe78505a15292b0ba23b17de.
Revert "TableGen: Emit statically generated hash table for runtime
libcalls (#150192)"
This reverts commit 769a9058c8d04fc920994f6a5bbb03c8a4fbcd05.
Reverted three changes because of a CMake error while building llvm-nm
as reported in the following PR:
https://github.com/llvm/llvm-project/pull/150192#issuecomment-3192223073
|
