Historically, the main example of *very* large string tables used the
`EmitCharArray` to work around MSVC limitations with string literals,
but that was switched (without removing the API) in order to consolidate
on a nicer emission primitive.
While this large string table in `IntrinsicsImpl.inc` seems to compile
correctly on MSVC without the work around in `EmitCharArray` (and that
this PR adds back to the nicer emission path), other users have
repeatedly hit this MSVC limitation as you can see in the discussion on
PR https://github.com/llvm/llvm-project/pull/120534. This PR teaches the
string offset table emission to look at
the size of the table and switch to the char array emission strategy
when the table becomes too large.
This work around does have the downside of making compile times worse
for large string tables, but that appears unavoidable until we can
identify known good MSVC versions and switch to requiring them for all
LLVM users. It also reduces searchability of the generated string table
-- I looked at emitting a comment with each string but it is tricky
because the escaping rules for an inline comment are different from
those of of a string literal, and there's no real way to turn the string
literal into a comment.
While improving the output in this way, also clean up the output to not
emit an extraneous empty string at the end of the string table, and
update the `StringTable` class to not look for that. It isn't actually
used by anything and is wasteful.
This PR also switches the `IntrinsicsImpl.inc` string tables over to the
new `StringTable` runtime abstraction. I didn't want to do this until
landing the MSVC workaround in case it caused even this example to start
hitting the MSVC bug, but I wanted to switch here so that I could
simplify the API for emitting the string table with the workaround
present. With the two different emission strategies, its important to
use a very exact syntax and that seems better encapsulated in the API.
Last but not least, the `SDNodeInfoEmitter` is updated, including its
tests to match the new output.
This PR should unblock landing
https://github.com/llvm/llvm-project/pull/120534 and letting us switch
all of
Clang's builtins to use string tables. That PR has all the details
motivating the overall effort.
Follow-up patches will try to consolidate the remaining users onto the
single interface, but those at least were easy to separate into
follow-ups and keep this PR somewhat smaller.
We currently have an issue where bf16 patters can be used to match fp16
types, as GISel does not know about the difference between the two. This
patch explicitly disables them to make sure that they are never used.
The opposite can also happen too, where fp16 patterns are used for
operators that should be bf16. So this also changes any operations with
bf16 types to now cause a fallback to SDAG.
The pass setup for GISel has been slightly adjusted to make sure that a
verify pass does not get added between AMD-SDAG and SIFixSGPRCopiesPass,
which otherwise can cause verifier issues when falling back.
- Bail out of TableGen if any asserts fail before running the backend.
- Add asserts to validate that the `Objects` and `Modes` lists for
various `HwModeSelect` subclasses are of same length.
- Eliminate equivalent check in CodeGenHWModes.cpp
Use this to remove a linear scan from CodeGenProcModel::hasReadOfWrite.
This reduces build time of RISCVGenSubtargetInfo.inc on by machine from
~6 seconds to ~3 seconds.
2 of the 3 callers of each of these already had a reference they
converted to index. Use that reference and make the one caller
that only has an index responsible for looking up the reference from it.
Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather than using a raw
`const char*`. Also try to use the `StringTable::Offset` type rather
than a raw `unsigned` where we can to avoid accidental increments or
other issues.
This is based on review feedback for the initial switch of options to a
string table. Happy to tweak or adjust if desired here.
Use this to improve performance of SubtargetEmitter::findWriteResources
and SubtargetEmitter::findReadAdvance. Now we can do a map lookup
instead of a linear search through all WriteRes/ReadAdvance records.
This reduces the build time of RISCVGenSubtargetInfo.inc on my
machine from 43 seconds to 10 seconds.
This patch adds a simplistic backend that gathers all target-specific
SelectionDAG nodes and emits descriptions for most of them.
This includes generating node enumeration, node names, and information
about node "prototype" that can be used to verify that a node is valid.
The patch also extends SDNode by adding target-specific flags, which are
also included in the generated tables.
Part of #119709,
[RFC](https://discourse.llvm.org/t/rfc-tablegen-erating-sdnode-descriptions/83627).
Pull Request: https://github.com/llvm/llvm-project/pull/123002
- Redefines `DXILAttribute` to denote a function attribute, compatible
to how it was define in DXC/LLVM 3.7
- Fix how `DXILAttribute` is emitted to be a struct of set attributes
instead of an "or" of the enums
- Implement the lowering of `DXILAttribute` to LLVM function attributes
in `DXILOpBuilder.cpp`. A custom mapping is defined.
- Audit all current ops to specify the correct attributes consistent
with DXC. This is done here to allow for testing.
- Update testcases in `llvm/test/CodeGen/DirectX` of all ops with
attributes to match that attributes are set
- Update testcases of ops that had previously incorrectly set attributes
to check there is no attributes set
- Defines `DXILProperty` to denote the other type of attributes from DXC
used to query properties.
- Emit `DXILProperty` as a struct of set attributes.
- Updates `DXIL.td` to specify applicable `DXILProperty`s on ops
Note: `DXILProperty` was referred to as 'queryable attributes' in design
discussion. Changed to property to allow for better expression in
`DXIL.td`
Resolves#114461Resolves#115912
Combine the EarlyOut and IsContiguous range check.
Also avoid "comparison is always false" warnings in emitted code when
the lower-bound check is against 0.
The function called find_if and converted the iterator to an index.
The caller then had to check the index being non-zero to know if the
find succeeded.
Seems better to just do the find and distance in the caller.
