This corresponds to frem, which for whatever reason is a first
class IR instruction. The backend has a heroic freestanding
implementation that should be nearly identical to what was here.
When the sum of two sub-normal values is not also subnormal, we need to
set the exponent to one.
Test case:
static volatile float x = 0x1.362b4p-127;
static volatile float x2 = 0x1.362b4p-127 * 2;
int
main (void)
{
printf("x %a x2 %a x + x %a\n", x, x2, x + x);
return x2 == x + x ? 0 : 1;
}
Signed-off-by: Keith Packard <keithp@keithp.com>
Reverts llvm/llvm-project#184656
This PR broke linking on Windows and possibly elsewhere. There are at
least 2 possible fixes. Revert while we decide on a single solution.
The check whether a stream is associated with a terminal or not and the
flushing of the stream in `std::print()` is needed only on Windows.
Additionally, the correct flush should be used. When `std::print` is
called with a C stream, `std::fflush()` should be used. When it is
called with C++ `ostream`, `ostream::flush()` should be called.
Because POSIX does not have a separate Unicode API for terminal output,
checking for terminal (`isatty`) and flushing is not needed at all.
Moreover, `isatty` has noticeable performance cost.
See also https://wg21.link/LWG4044.
Fixes#70142
Adjust `mlir::Value`'s `operator<<` and `dump()` function so that it can
be safely used with multithreading enabled.
Similar to `mlir::Operation` which uses `OpPrintingFlags` with
`localScope` enabled in printing methods.
Using `Value::print(raw_ostream &os)` creates default `OpPrintingFlags`
and with these flags print method is called on `getDefiningOp()`. With
`localScope` disabled by default, `findParent()` could go all the way up
to the `ModuleOp` which can be outside of the pass scope.
We had an instance of it in our project when multiple OperationPasses
were ran concurrently. Trying to print or dump `mlir::Value` in one of
the passes resulted in crash due to failed verifiers that got triggered
on parent op before the print.
Launch this perf job with the others at the beginning of the aggregation
process.
Extracting buildid-list from perf data is not a costly process, so it
can be performed by default. This provides a distinct advantage when
this dataset is required in other perf2bolt stages as well.
Please see PR #171144.
See
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#experimental-non-cascading-changes
for the full background.
In short, we want to cut off the dependencies to improve the
recompilation time.
And namespace is special, as the same namespace can occur in many TUs.
This patch tries to clean up unneeded reference to namespace from other
module file. The touched parts are:
- When write on disk lookup table, don't write the merged table. This
makes the ownership/dependency much cleaner. For performance, I think
the intention was to make the cost of mergin table amortized. But in our
internal workloads, I didn't observe any regression if I turn off
writing the merged table.
- When writing redeclarations, only write the ID of the first namespace
and avoid referenece to all other previous namespaces. (I don't want to
write the first namespace either... but it is more complex).
- When writing the name lookup table, try to write the local namespace.
@jtstogel @mpark I want to invite you to test this with your internal
workloads to figure out the correctness and the performance impact on
this.
I know I can make the change clean for you by inserting code guarded by
"if writing named module" but I think it will be much better if we can
make the underlying implementation more homogeneous if possible.
In #124103 we changed the size of various iostream objects, which turns
out to be ABI breaking when compiling non-PIE code.
This ABI break is safe to fix, since for any programs allocating more
memory for the iostream objects, the remaining bytes are simply unused
now.
Fixes#185724
This reverts commit 077991463253b9295f291d4e4d2078521e518717.
Need to revert this follow up commit to 6758becb8f19593f5341b2e4d575dbf411ad706e
in order to revert an earlier commit which caused 2 test failures on a bot.
The log implementation was originally ported from
rocm device libs way back in 44b6117dfde30d6cc292fabca8ecb0cef4657f7a.
Update this to a version derived from the latest. Leaves the float and
half cases alone.
Looking back in the history as far as edb874b2310dc, there was a
sentence here to say we don't have an equivalent.
Put that sentence back, and make the first line a header as it was in
that HTML version.
VertexID semantic only allows uint as type. Looking at DXC, it seems the
uint16 variant is allowed, but that's not documented. Until we figure
out the real behavior, we restrict the type to only uint.
Similar to what we already do for SHL(1, Amt) - just insert the (locally
shifted) bit into a zero vector in the correct element
After this I just need to handle SRA(SIGN_BIT, Amt) and SHL/SRL(-1, Amt)
mask creation patterns and I think that's it for #132601
The recursion here has potentially exponential complexity. Avoid this by
limiting the depth of recursion.
An alternative would be to memoize the results. I went with the simpler
depth limit on the assumption that we don't particularly care about very
deep value chains here.
Fixes https://github.com/llvm/llvm-project/issues/185905.
Add a config to document building compiler-rt for a baremetal RISCV
target. It works on a Linux host, but not a macOS host, due to CMake
issues.
Documenting building libcxx and libcxxabi for these targets is left to a
follow-up.
Similar to commit 557efc9a8b68628c2c944678c6471dac30ed9e8e (2022).
cl::ZeroOrMore is the default for cl::list and is unnecessary for
cl::opt
since the "may only occur zero or one times!" error was removed.
Also remove cl::init(false) on modified cl::opt<bool> lines.
Relocate HTTPClient and HTTPServer from the Debuginfod library to
llvm/Support/HTTP so they can be reused by other components.
---------
Relanding with fixes in CMakeLists.txt to account for dependency to new
LLVMSupportHTTP in tools.
---------
Co-authored-by: Alexandre Ganea <aganea@havenstudios.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
When >1 predecessors of BB are identical, try to merge them into ONE.
---
Here is a simplified example (`sink` and `bb*`s share the same
predecessor `entry`, hindering the existing uncond br folding to
optimize such a case):
```diff
- entry:
- switch to %br1, %br2, %br3, %sink
- bb1:
- br label %sink
- bb2:
- br label %sink
- bb3:
- br label %sink
- sink:
- %ret = phi i8 [ 0, %bb1 ], [ 0, %bb2 ], [ 0, %bb3 ], [ -1, %entry ]
+ entry:
+ switch to %br1, %sink
+ bb1:
+ br label %sink
+ sink:
+ %ret = phi i8 [ 0, %bb1 ], [ -1, %entry ]
```
Actually, `simplifyDuplicateSwitchArms` did similar things in a very
limited scope (only for switch arms), this patch generalizes its logic
to handle any BB with >1 identical predecessors.
---
This PR lands the
[discussion](https://github.com/dtcxzyw/llvm-opt-benchmark/pull/3033#discussion_r2506973226),
i.e., "merge identical predecessor bottom to up", and implements the
suggestion of
https://github.com/llvm/llvm-project/pull/114262#issuecomment-2448140669.
- IR diff: https://github.com/dtcxzyw/llvm-opt-benchmark/pull/3537
- CompTime Impact:
https://github.com/dtcxzyw/llvm-opt-benchmark/pull/3538
This was originally ported from rocm device libs in
d6d0454231ac489c50465d608ddf3f5d900e1535. Update for
more recent changes that were made there. This avoids
bithacking and improves value tracking. This also allows
using a common code path for all types.
f7ca74f600
has added basic check for register overlap.
Furthermore, we need to add extra check for register group overlap since
more registers will be occupied in segment load.
This change marks the test
`modules-symlink-dir-from-module-incremental.c` as "unsupported" on AIX.
The test relies on the -F flag to specify framework search paths, which
is a driver feature exclusive to Darwin, and it is not supported on the
AIX target.
Co-authored-by: Aditya Chaudhary <aditya.chaudhary1@ibm.com>
Fix#180648 caused by an unhandled `Argument` for parameters exceeding
ABI size limits. This patch explicitly emits an `alloca` for the `Argument` in
the entry block to ensure correct address resolution.
\#182792 makes it so that these structs have an alignment of 1. This
needs to be fixed in a recently added test (landed after the most recent
premerge run of the test).
This test update is expected behavior.
The Sub instruction cost and the shift-by-zero handling costs (ICmp +
Select) are only needed when the shift amount is non-constant. Move them
inside the `!OpInfoZ.isConstant()` guard to avoid overestimating cost
for constant shift amounts.
The overestimated scalar cost caused SLP vectorizer to incorrectly
prefer vectorizing funnel shifts with constant shift amounts, since SLP
compares vector cost against scalar cost and a falsely high scalar cost
makes vectorization appear more profitable than it actually is.
Fixes#181308.
This PR adds latency/throughput for all RVV permutation instructions to
the andes45 series scheduling model.
We use the default cycle for permutation instructions since we are
unable to model the Latency and ReleaseAtCycles accurately now.
## Summary
I hit the same issue as in #168360 when upgrading to LLVM 21 with
clang-tidy reporting cryptic:
`error: missing '(' after '__has_feature'`
Further investigation confirmed that the issue is localized to
`modernize-use-trailing-return-type` and only happens with C++20+ and llvm
21 system headers (where `__has_feature` started to be used by libc++).
Initial non-localized repro had this error firing 7k+ on LLVM 21, but
when I switched to HEAD the incidence dropped to just 5 'check()' calls
firing. The drop in incidence is likely to be related to
https://github.com/llvm/llvm-project/pull/151035 as there are no other
plausibly relevant changes.
However, as I was still hitting the issue with HEAD, this helped develop
the standalone repro (below) that still triggered against HEAD and
develop the fix. The issue was in `classifyTokensBeforeFunctionName()`
when lexing return type span and encountering builtin macros like
`__has_feature`, `__has_builtin`, `__has_extension` etc would not bail
out with 'std::nullopt' as these were not registered as function-like,
but only as builtin. The change adds the check to
`classifyTokensBeforeFunctionName()` to return 'std::nullopt' not only
when there is a function-like macro, but also adds a condition for
builtins.
## Root cause
`RegisterBuiltinMacro("__has_feature")` sets `isBuiltinMacro=true` but not `isFunctionLike=true`. When `classifyTokensBeforeFunctionName` later sees `__has_feature` as a raw identifier, the filter uses `!MI || MI->isFunctionLike()`, which is false for this builtin, so the token is not treated as a function-like macro and passes through. `classifyToken()` then records `{__has_feature, EOF}` in the preprocessor state. On the next `PP.Lex()`, `ExpandBuiltinMacro` runs and calls `EvaluateFeatureLikeBuiltinMacro`, which expects an opening `(` but gets EOF instead, leading to the error.
## Reproducer
https://clang-tidy.godbolt.org/z/T1WMjxn5bFixes#168360
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
For ms_struct structs on Itanium layout targets, the packed attribute is
ignored on bit-fields (2014 commit
76e1818a2b1248579557de2927c135c322577c82), mismatching the GCC behavior.
Remove the `!IsMsStruct` guard to fix it.
There may be some BB to COPY fgr64cc register, and the fgr64cc register
is set by the previous BB.
We add a new pass called MipsSetMachineRegisterFlags, in which we set
We introduce a new pass called MipsSetMachineRegisterFlags, in which we
set NoSWrap flag for all instructions that works with fgr64cc registers.
And in copyPhyRegister, we allow the COPY instruction with NoSignWrap
from the double float registers to gpr32.
Don't mention the possible expectation that the extension %LOC() could
appear when emitting the error messages for a completely missing primary
expression; it's just confusing.
The compiler implements CUDA object entity attributes in module files by
emitting "attributes()" statements after the type declaration statement
for the object. This works fine for variables, but not at all for
derived type components -- the "attributes()" statement is not allowed
in a derived type definition, and the module file isn't readable later
when USE'd. The fix is to emit the attribute as part of the type
declaration statement or component declaration statement instead.
With MTE, the issue is caught by hardware and libmalloc records a
different message: "BUG IN CLIENT OF LIBMALLOC: MTE tag mismatch
(probable double-free)". Update the test accordingly.
