This patch fixes an issue with the legalization of G_LOAD where the
presence of .lowerIfMemSizeNotByteSizePow2 before .clampMaxNumElements
was causing issues for vectors which matched that condition.
Such vectors would be lowered into per-element loads instead of being
split up into 128-bit chunks.
Add DXIL module flag bit offset for SHADER_FEATURE_FLAG.
Added DXIL_MODULE_FLAG for DXIL module flag which does not have feature flag.
Use DXILModuleFlags for ComputedShaderFlags instead of
ShaderFeatureFlags.
ComputedShaderFlags::getFeatureFlags() was added to get FeatureFlags.
Rename DXContainerGlobals::getShaderFlags to DXContainerGlobals::getFeatureFlags.
Fixes#57925
This resolves an issue in clang-format where `new` and `delete` were
incorrectly formatted as keywords in C files. The fix modifies
`TokenAnnotator::spaceRequiredBetween` to handle `new` and `delete` when
used as identifiers for function pointers in structs in C code.
This is part of #70452 that changes the type used for the external
interface of MMO to LocationSize as opposed to uint64_t. This means the
constructors take LocationSize, and convert ~UINT64_C(0) to
LocationSize::beforeOrAfter(). The getSize methods return a
LocationSize.
This allows us to be more precise with unknown sizes, not accidentally
treating them as unsigned values, and in the future should allow us to
add proper scalable vector support but none of that is included in this
patch. It should mostly be an NFC.
Global ISel is still expected to use the underlying LLT as it needs, and
are not expected to see unknown sizes for generic operations. Most of
the changes are hopefully fairly mechanical, adding a lot of getValue()
calls and protecting them with hasValue() where needed.
Prior to this commit, clang would fail to produce a constant value for
`b` in:
```c++
struct base {
};
struct s : base {
int z;
};
constexpr auto b = std::bit_cast<s>(0x12);
```
e.g. https://godbolt.org/z/srrbTMPq4
The previous implementation decomposes tanh(x) into
`(exp(2x) - 1)/(exp(2x)+1), x < 0`
`(1 - exp(-2x))/(1 + exp(-2x)), x >= 0`
This is fine as it avoids overflow with the exponential, but the whole
decomposition is computed for both cases unconditionally, then the
result is chosen based off the sign of the input. This results in doing
two expensive exp computations.
The proposed change avoids doing the whole computation twice by
exploiting the reflection symmetry `tanh(-x) = -tanh(x)`. We can
"normalize" the input to be positive by setting `y = sign(x) * x`, where
the sign of `x` is computed as `sign(x) = (float)(x > 0) * (-2) + 1`.
Then compute `z = tanh(y) `with the decomposition above for `x >=0` and
"denormalize" the result `z * sign(x)` to retain the sign. The reason it
is done this way is that it is very amenable to vectorization.
This method trades the duplicate decomposition computations (which takes
5 instructions including an extra expensive exp and div) for 4 cheap
instructions to compute the signs value
`arith.cmpf `(which is a pre-existing instruction in the previous impl)
`arith.sitofp`
`arith.mulf`
`arith.addf`
and 1 more instruction to get the right sign in the result
5. `arith.mulf`.
Moreover, numerically, this implementation will yield the exact same
results as the previous implementation.
As part of the relanding, a casting issue from the original commit has
been fixed, i.e. casting bool to float with `uitofp`. Additionally a
correctness test with `mlir-cpu-runner` has been added.
Since we implemented `copyable-box` in
(https://reviews.llvm.org/D102135,
6829db727e),
this issue got addressed.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Following of https://github.com/llvm/llvm-project/pull/82160
The reason why the above PR fails is that the `--sysroot` has lower
priority than the libc++ built from the same source. On the one hand, it
matches the codes behavior. We will add the built libc++ project paths
in the ToolChain class. But we will only add the path related to sysroot
in Linux class, which is derived from the ToolChain classes. So the
paths of just built libc++ is in the front of the paths relative to
sysroot. On the other hand, the behavior should be good from the higher
level. Since the just built libc++ has the same version number with the
just built clang, so it makes sense that these 2 compilers just matches.
So for patch it self, I hacked it by using resource dir in the test
since the resource dir has the higher priority, which is not strongly
correct since we won't do that in practice.
@kaz7 would you like to test on your environment to avoid this get
reverted again?
On the libc++ side, it shows that it lacks a `modules.json` file for the
just built libc++ directory. If we don't have that, it will be
problematic to use std modules from the just built clang and libc++
pair. Then it is not good. And I feel it may be problematic for future
compiler/standard library developers. So I feel this is somewhat a
libc++ issue that need to be fixed.
Also if we don't like the hacked test in the current patch, we must wait
for libc++ to fix this to proceed. But I feel this is somewhat odd since
the test of clang shouldn't dependent on libc++.
CC: @mordante
---------
Co-authored-by: Mark de Wever <koraq@xs4all.nl>
MSVC fails to parse this construct, leading to
MlirTranslateMain.cpp(70): error C2065: 'inputSplitMarker': undeclared identifier
Just switching to brace init works around the issue
Definitions like this did not work as intended:
let is_flat_scratch = 1 in {
let SubtargetPredicate = HasFlatScratchSVSMode in
def _SVS : FLAT_Scratch_Load_Pseudo<opName, regClass, HasTiedOutput, 1,
1>,
FlatScratchInst<opName, "SVS">;
let SubtargetPredicate = HasFlatScratchSTMode in
def _ST : FLAT_Scratch_Load_Pseudo<opName, regClass, HasTiedOutput, 0,
0, 0>,
FlatScratchInst<opName, "ST">;
}
They tried to override SubtargetPredicate, but then it was overridden
again (back to its default value) by setting is_flat_scratch, which
caused SubtargetPredicate to be recalculated in the base class. (This
patch also removes some overrides of SubtargetPredicate that are
redundant due to being recalculated in the base class.)
Fix this by pushing overrides of is_flat_scratch and is_flat_global "in"
as far as possible. This has the added benefit that there is no need to
override them around groups of Pseudo definitions like this:
let is_flat_global = 1 in {
defm GLOBAL_ATOMIC_CMPSWAP : FLAT_Global_Atomic_Pseudo
<"global_atomic_cmpswap",
VGPR_32, i32, v2i32, VReg_64>;
...
}
which are plainly Global instructions anyway.
Verified by inspecting the output of TableGen. It seems to be NFC in
practice.
When speculating an instruction in `InstCombinerImpl::FoldOpIntoSelect`,
the call may result in undefined behavior. This patch drops all
UB-implying attrs/metadata to fix this.
Fixes#85536.
To match the entrypoints and types we need to exclude __atexithandler_t
and __qsortrcompare_t, as well as qsort_r, which is a GNU extension.
This is a reland of llvm/llvm-project#85030.
This patch makes NEON-enabled AArch64 backend expand the `sin, cos, pow,
log, log2, log10, exp, exp2, exp10` intrinsics for `v1f64` data type,
all of which caused selection failure before this patch.
Fixes https://github.com/llvm/llvm-project/issues/83729
These types and conversion functions are used in embedded development.
Note that we cannot yet include other entrypoints such as asctime
because `src/time/time_utils.h` unconditionally uses `EOVERFLOW`, which
is only defined in POSIX and not in C standard. This issue is tracked by
#85556.
At the moment, loads introduced by multiply fusion may be placed after
an objects lifetime has been terminated by lifetime.end. This introduces
reads to dead objects.
To avoid this, first collect all lifetime.end calls in the function.
During fusion, we deal with any lifetime.end calls that may alias any of
the loads.
Such lifetime.end calls are either moved when possible (both the
lifetime.end and the store are in the same block) or deleted.
PR: https://github.com/llvm/llvm-project/pull/84914
Right now the algorithm does not exit on unpredictable values. It
waits until all the paths have been enumerated to see if any of
those paths have that value. Waiting this late leads to a lot of
wasteful computation and higher compile time.
In this patch I have added a heuristic that checks if the value
comes from the same inner loops as the switch, if so, then it is
likely that the value will also be seen on a threadable path and
the code in `getStateDefMap()` return an empty map.
I tested this on the llvm test suite and the only change in the
number of threaded switches was in 7zip (before 23, after 18).
In all of those cases the current algorithm was partially threading
the loop because it was hitting a limit on the number of paths to
be explored. On increasing this limit even the current algorithm
finds paths where the unpredictable value is seen.
Compile time(with pass enabled by default and this patch):
https://llvm-compile-time-tracker.com/compare.php?from=8c5e9cf737138aba22a4a8f64ef2c5efc80dd7f9&to=42c75d888058b35c6d15901b34e36251d8f766b9&stat=instructions:u
This adds basic support for calling the verifier on global declarations
that are expected to represent symbol exports. The driver now
exclusively uses this for knowing what symbols make up a TBD file.
Future patches will check against the dylib's symbol table.
* A lot of `tapi installapi` options are already shared with clang, but
not all. This patch handles installapi-specific options by filtering for
them in the initial argv input, then passing the rest to the clang
driver.
* Installapi not only generates a text file but also reports to library
developers when there are inconsistencies between an interface and its
implementation. To allow this, add support for reporting installapi
diagnostics. This will be leveraged in the verifier service.
For Mach-O, ld64 supports the -fobjc-relative-method-lists flag which
changes the format in which method lists are generated. The format uses
delta encoding vs the original direct-pointer encoding.
This change adds support to llvm-objdump and llvm-otool for
decoding/dumping of method lists in the delta format. Previously, if a
binary with this information format was passed to the tooling, it would
output invalid information, trying to parse the delta lists as pointer
lists.
After this change, the tooling will output correct information if a
binary in this format is encountered.
The output format is closest feasible match to XCode 15.1's otool
output. Tests are included for both 32bit and 64bit binaries.
The code style was matched as close as possible to existing
implementation of parsing non-delta method lists.
Diff between llvm-objdump and XCode 15.1 otool:
Note: This is a retry of this PR:
https://github.com/llvm/llvm-project/pull/84250
On the original PR, the armv7+armv8 builds were failing due to absolute
offsets being different.
Co-authored-by: Alex B <alexborcan@meta.com>
