Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D139379
The SigCtx function lazily allocates a ThreadSignalContext, and stores it
in the ThreadState. This function may be called by various interceptors and
the signal handler itself.
If SigCtx itself is interrupted by a signal, then (prior to this fix) there
was a possibility of allocating two ThreadSignalContexts. This not only
leaks, it fails to deliver the signal to the program's signal handler, as
the recorded signal is overwritten by the new ThreadSignalContext.
Fix this by using a CAS to swap in the ThreadSignalContext, preventing the
race. Add a test for this case.
Reviewed By: dvyukov, melver
Differential Revision: https://reviews.llvm.org/D140582
Complex scenario, but reports when there's both a use-after-free and
buffer-underflow that is in-page (i.e. doesn't touch the guard page)
ended up generating a pretty bad report:
'Use After Free at 0x7ff392e88fef (18446744073709551615 bytes into a
1-byte allocation at 0x7ff392e88ff0) by thread 3836722 here:'
(note the 2^64-bytes-into-alloc, very cool and good!)
Fix up that case, and add a diagnostic about when you have both a
use-after-free and a buffer-overflow that it's probably a bogus report
(assuming the developer didn't *really* screw up and have a uaf+overflow
bug at the same time).
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D139885
We incorrectly install the atfork handlers multiple times in the test
harness, tracked down to the default parameter used by
CheckLateInitIsOK. This manifested in a hang if running the tests with
--gtest_repeat={>=2} as the atfork handler ran multiple times, causing
double-lock and double-unlock, which on my machine hung.
Add a check-fail for this case as well to prevent this from happening
again (it was difficult to track down and is an easy mistake to make).
Differential Revision: https://reviews.llvm.org/D139731
When rooted with PHIs, a vectorization tree may have another node with PHIs
which have roots as their operands. We cannot ignore ordering information
for root in such a case.
Differential Revision: https://reviews.llvm.org/D141309
singlethread fences only synchronize with code running on the same hardware thread (i.e. signal handlers). Because of this, we need to prevent instruction reordering, but do not need to emit hardware fence instructions.
The implementation strategy here matches many other backends. The main motivation of this patch is to introduce the MEMBARRIER node and get some test coverage for it.
Differential Revision: https://reviews.llvm.org/D141311
This was broken for 1 element vectors and trying to create invalid
casts. We can directly store any type just fine, so don't bother with
this buggy conversion logic.
This adds the missing handling for defs for target index operands, as is
already done for registers.
There are two kinds of target indices: local indices and stack operands.
- Locals are something similar to registers in Wasm-land. For local
indices, we can check for local-defining instructions (`local.set` or
`local.tee`).
- Wasm is a stack machine, so we have values in certain Wasm value stack
location, which change when Wasm instructions produce or consume
values. So basically any value-producing instrucion, i.e., instruction
with defs, can change values in the Wasm stack. But I think we don't
need to worry about this here, because `WebAssemblyDebugFixup`, which
runs right before this analysis, makes sure to insert terminating
`DBG_VALUE $noreg` instructions whenever a stack value gets popped.
After `WebAssemblyDebugFixup`, there shouldn't be any `DBG_VALUE`s for
stack operands that don't have a terminating `DBG_VALUE $noreg` within
the same BB.
So this CL only works on `DBG_VALUE`s for locals. When we encounter a
`local.set` or `local.tee` instructions, we delete `DBG_VALUE`s for
those target index locations from the open range set, so they will not
be availble in `OutLocs`. For example,
```
bb.0:
successors: %bb.1
DBG_VALUE target-index(wasm-local) + 2, $noreg, "var", ...
...
local.set 2 ...
bb.1:
; predecessors: %bb.0
; We shouldn't add `DBG_VALUE target (wasm-local) + 2 here because
; it was killed by 'local.set' in bb.0
```
After disabling register coalescing at -O1, the average PC ranges
covered for Emscripten core benchmarks is currently 20.6% in the LLVM
tot. After applying D138943 and this CL, the coverage goes up to 57%.
This also enables LiveDebugValues analysis in the Wasm pipeline by
default.
Reviewed By: dschuff, jmorse
Differential Revision: https://reviews.llvm.org/D140373
This enables `LiveDebugValues` analysis for Wasm. `DBG_VALUE`s expire at
the end of a BB, and this is the analysis extends their lifetime when
possible, greatly increasing the coverage of variable debug info.
Specifically, this removes the current constraint that this analysis is
only used with physical registers, which was first introduced in D18421,
because Wasm uses only virtual registers. I don't think there's anything
inherent in this analysis that only applies to physical registers; it
was just because all targets using this analysis ran this at the end of
their compiliation pipeline, at which point all their vregs had been
allocated, and Wasm's debug info infrastructure was not really set up
yet, so it was not using it.
This adds supports to Wasm-specific target-index operands, defined in
2166d9529a/llvm/lib/Target/WebAssembly/WebAssembly.h (L87-L100).
Among these, `TI_LOCAL`, `TI_LOCAL_INDIRECT`, and `TI_OPERAND_STACK` are
used by Wasm `DBG_VALUE` instructions.
This does not yet handle mutable target indices, i.e., this does not
terminate a `DBG_VALUE` for a local index when we encounter a new
`local.set` or `local.tee`. It will be implemented as a follow-up.
Reviewed By: dschuff, jmorse
Differential Revision: https://reviews.llvm.org/D138943
Currently it is just an empty implementation to allow the project to link.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D141147
faa35fc87370 fix the case of negative input shift. But when `c1`, `c2` is not the same side, it will also cause negative shift amount.
And that negative shift amount can't normalize by urem. So add one more bit size to normalize the last shift amount.
Fix: https://github.com/llvm/llvm-project/issues/59898
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D141363
Use the module location instead of unknown location if the imported
LLVM IR module does not have more precise debug information.
Additionally, use the diagMD function to print the metadata instead
of just the metadata kind if the import fails.
Reviewed By: definelicht
Differential Revision: https://reviews.llvm.org/D141357
In some fir.embox cases as shown in the test, the type descriptor
was not correctly found and the descriptor was populated with a null in the
addendum. This patch fixes this issue.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141383
This patch allows clang-tidy to replace traditional for-loops where the
container type inherits its `begin`/`end` methods from a base class.
Test plan: Added unit test cases that confirm the tool replaces the new
pattern.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D140307
There were two (small) bugs causing crashes in the analysis. This patch fixes both of them.
1. An enum value was accessed as a class member. Now, the engine gracefully
ignores such member expressions.
2. Field access in `MemberExpr` of struct/class-typed global variables. Analysis
didn't interpret fields of global vars, because the vars were initialized before
the fields were added to the "allowlist". Now, the allowlist is set _before_
init of globals.
Differential Revision: https://reviews.llvm.org/D141384
Also regenerates the AST matcher documentation. This matcher is tested
in TEST(HasImplicitDestinationType, MatchesSimpleCase) and
TEST(HasImplicitDestinationType, DoesNotMatchIncorrectly) in
ASTMatchersTraversalTest.cpp.
This will be used to implement the case insensitive str{,n}casecmp
This was initially reverted because it broke tests on arm platforms.
Unfortunately, it didn't break on my arm machine, but I suspect the
problem was the old comparator returned char and not int.
Differential Revision: https://reviews.llvm.org/D141235
The problem was whitespace between the comment and the code for the
matcher. Rather than fix the script, I went the easier route and
removed the offending newline. If this problem comes up again though,
we should consider making the script less fragile.
This bit-hack transform would cause the new test to infinite loop
after 21d3871b7c90f85b3ae.
The deleted transform has existed for a very long time,
but the profitable parts appear to be handled by other
folds now. This fold could replace 2 instructions with
4 instructions, so it was always in danger of going
overboard.
No tests regress by removing the whole thing.
Note, when regenerating the documentation for this change, no changes
were made to the HTML file. There is an existing bug with the AST
matcher python script that fails to handle hasBody() specifically. So
this commit is to correct the internal documentation but another change
will be needed to fix the public documentation.
When `strict = true`, only pre-existing and newly-created ops are rewritten and/or folded. Such ops are stored in `strictModeFilteredOps`.
Newly-created ops were previously added to `strictModeFilteredOps` after calling `addToWorklist` (via `GreedyPatternRewriteDriver::notifyOperationInserted`). Therefore, newly-created ops were never added to the worklist.
Also fix a test case that should have gone into an infinite loop (`test.replace_with_new_op` was replaced with itself, which should have caused the op to be rewritten over and over), but did not due to this bug.
Differential Revision: https://reviews.llvm.org/D141141
Android only provides this function on API 28+; fix libc++ builds when
targeting older API levels.
Reviewed By: arichardson, #libc, philnik
Differential Revision: https://reviews.llvm.org/D141184
Reinstate use of FakeSection class to avoid constructing SectionChunk
from unintialised coff_section in FakeSectionChunk constructor.
Issue was caused by commit 5a58b19f9c93f3ac51bcde318508131ae78aa10c,
"[LLD] Remove global state in lld/COFF".
Merges `TransferOptions` into the newly-introduced
`DataflowAnalysisContext::Options` and removes explicit parameter for
`TransferOptions`, relying instead on the common options carried by the analysis
context. Given that there was no intent to allow different options between calls
to `transfer`, a common value for the options is preferable.
Differential Revision: https://reviews.llvm.org/D140703
There are a lot of variants of atomic operations, and AArch64 has several
distinct options to codegen them, and does different things depending on
available features, architecture version and optimisation level. The current
testing for atomic operations has been added gradually over time and does not
give full coverate. Given how complex the codegen for atomic operations is, it
is valuable to cover the entire parameter space, i.e. test them all. The
resulting set of tests serve also as a reference for how each is codegened.
In order to keep the test files readable and avoid constant updating for
unrelated codegen changes, the test outputs are filtered to only include the
relevant instructions. This shows for each operation and feature which codegen
approach is taken (e.g. ll/sc loop, atomic instruction, library call).
The following parameter space is tested:
- feature: +lse, +rcpc, etc
- optimisation level: O0, O1 (covers GISel and SelectionDAG)
- atomic instruction: load, store, cmpxchg, atomirmw*
- size: i8, i16, i32, i64, i128
- aligned/unaligned accesses
- endianness: big, little
- atomic ordering: release, acquire, etc
- load atomic only: const/non-const
- cmpxchg only: weak/strong
- atomicrmw: update operation (add, sub, etc)
Notably not covered:
- volatility: there should be no difference between volatile/non-volatile
- atomicrmw fadd/fsub
The files are split by triple, LLVM instruction, and feature. This makes it
easy to diff between features and endianness for a given instruction.
The file that generates the tests is included.
There are 70 test files with an average of 2800 lines each.
Differential Revision: https://reviews.llvm.org/D141064
Add a verifier to the TransformOpInterface ensuring that operations
implementing the interface define memory effects on their operands and
results.
Add the missing effects to TileToForeachThreadOp, specifically for
operands that were added at a later version of the op without modifying
`getEffects` accordingly.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D141371
Extract a static method to call the MLIR builders that translate LLVM IR
instructions to MLIR LLVM dialect operations. This change ensures the
MLIR builders have to use the moduleImport argument rather than calling
the import methods directly. As a result, both the intrinsic and the
instruction MLIR builders have to use a moduleImport argument and none
of them has direct access to private moduleImport methods. The revision
thus enforces consistent MLIR builder implementations for instructions
and intrinsics.
The revision also moves parseDataLayoutAlignment closer to its use.
Reviewed By: Dinistro
Differential Revision: https://reviews.llvm.org/D141265
