This patch utilizes the helper function implemented in D149699 and thus folds the following cases:
```
bitreverse(logic_op(x, bitreverse(y))) -> logic_op(bitreverse(x), y)
bitreverse(logic_op(bitreverse(x), y)) -> logic_op(x, bitreverse(y))
bitreverse(logic_op(bitreverse(x), bitreverse(y))) -> logic_op(x, y) in multiuse case
```
Reviewed By: goldstein.w.n, RKSimon
Differential Revision: https://reviews.llvm.org/D151246
Fold the following case on IR InstCombine pass. This patch includes the new test cases for this optimization
```
bitreverse(logic_op(x, bitreverse(y))) -> logic_op(bitreverse(x), y)
bitreverse(logic_op(bitreverse(x), y)) -> logic_op(x, bitreverse(y))
bitreverse(logic_op(bitreverse(x), bitreverse(y))) -> logic_op(x, y) with multi-use
```
Reviewed By: goldstein.w.n
Differential Revision: https://reviews.llvm.org/D151245
PageMap is allocated with MAP_ALLOWNOMEM if there's no static buffer
left. So it can be failed and return nullptr without any assertion
triggered. Instead of crashing in the releaseToOSMaybe in the middle,
just return and let the program handles the page failure.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D151379
This was originally added to preserve FMF on SETCC. Unfortunately,
it also incorrectly preserves nuw/nsw on ADD/SUB in some cases.
There's also no guarantee the new opcode is even the same opcode
as the original node.
This patch removes the code and adds code to explicitly preserve
FMF flags in the SETCC promotion function.
The other test changes are from nuw/nsw not being preserved. I
believe for all these tests it was correct to preserve the flags,
so we need new code to preserve the flags when possible. I'll post
another patch for that since it's a riskier change.
This should unblock D150769.
Differential Revision: https://reviews.llvm.org/D151472
Currently, the method `GetAttributeAddressRanges` takes a DWARFRangeList as a
parameter, just to immediately clear it. The method also returns the size of
this list. Such an API was obfuscating the intent of the call sites (it's not
clear from the method name what it returns) and it was obfuscating redundant
checks on the size of the list.
This commit refactors the method to return the list and to also make the call
sites use the more explicit `IsEmpty` method.
Differential Revision: https://reviews.llvm.org/D151451
RenderFrame() has several implementations, which was missed in
01cea39f8e11012ac96b36ef60bfaf2f3b64320b.
Fix the one in sanitizer_symbolizer_markup.cpp.
Reported-by: gulfem
This patch is to remove the conversion of the actual argument that
is associated with the dummy argument specified with the IGNORE_TKR
directive.
Commit on behalf of @danielcchen
Differential Revision: https://reviews.llvm.org/D151401
When looking for payload op replacements, rank-expanding InsertSliceOps of dynamically-typed tensors are now supported.
Differential Revision: https://reviews.llvm.org/D151444
Add a helper function that computes if two SSA values have the same value, utilizing the `ValueBoundsOpInterface` infrastructure. Two SSA values have the same value, an equality bound of 0 can be derived for their subtraction.
The helper function can also be used to determine if two tensor dimension sizes are equal.
Differential Revision: https://reviews.llvm.org/D151443
The inline history makes sure that we don't keep inlining due to mutual devirtualization. But this gets forgotten between inliner invocations.
So mark the inlined calls as noinline so we respect previous inline history decisions.
This overlaps with D121084, but they're not redundant since we may not inline completely through a child SCC, but we still want a cost multiplier when that happens.
See discussions in D145516.
Reviewed By: jmorse
Differential Revision: https://reviews.llvm.org/D150989
This line has been misplaced since it was introduced in 2011 by
c26e4454035a4160cffc3c865cf83be194ca38c4.
Differential Revision: https://reviews.llvm.org/D151425
There is no initialization of the data between allocation
and first getBeginLoc call.
allocation: llvm-project/clang/lib/AST/ASTContext.cpp:3022
use: llvm-project/clang/lib/AST/TypeLoc.cpp:222
Msan report https://reviews.llvm.org/P8306
Reviewed By: thurston
Differential Revision: https://reviews.llvm.org/D150499
In some scenarios, a SELECT CASE could cause an error while lowering to FIR.
This was caused by a spurious extra branch added after the end statement.
Fixes#62726
Differential Revision: https://reviews.llvm.org/D151118
Certain InsertSliceOps, that do not use elements from the destination, are treated like casts when looking for replacement ops. Such InsertSliceOps are typically rank expansions.
Tensors with dynamic shape are not supported at the moment.
Also adds test cases for the TrackingListener.
Differential Revision: https://reviews.llvm.org/D151422
Since the scf.forall is now consumed by the fuse into
containing op, we need to return a handle to the new scf.forall.
This patch does that and also ensures that the new bbArg
added to the scf.forall is used in its body.
Differential Revision: https://reviews.llvm.org/D151418
Need to finalize the DIBuilder to avoid leak sanitizer errors
like this:
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x55c99ea1761d in operator new(unsigned long)
#1 0x55c9a518ae49 in operator new
#2 0x55c9a518ae49 in llvm::MDTuple::getImpl(...)
#3 0x55c9a4f1b1ec in getTemporary
#4 0x55c9a4f1b1ec in llvm::DIBuilder::createFunction(...)
For block arg locs a common case is no/uknown location (where the producer
signifies they don't care about blockarg location). Also avoid needing to
dynamically resize opnames during parsing.
Assumed to be post lazy loading change, so chose version 3.
Differential Revision: https://reviews.llvm.org/D151038
Currently, the dialects precede the registered operations in the context object, which means that the latter is destroyed first. At the same time, Operation::~Operation dereferences the registered operation when destroying properties, which can cause use-after-free (e.g. if a dialect owns an op). This patch fixes that by changing the order of the members so that dialects come after registered operations.
Differential Revision: https://reviews.llvm.org/D151440
We already have -print-on-crash which dumps the IR to stderr on a crash, but it's more useful to dump to a file.
Introduce -print-on-crash-path to dump the IR to a file.
Making -print-on-crash a string option is confusing if you only pass -print-on-crash and it swallows up the next command line arg, which is why this is a new option.
Perhaps we could retire the dump to stderr version if people don't use it, but not sure how much people find that useful.
Reviewed By: jamieschmeiser
Differential Revision: https://reviews.llvm.org/D151170
# Darwin Sanitizers Stable ABI
We wish to make it possible to include the AddressSanitizer (ASan) runtime implementation in OSes and for this we need a stable ASan ABI. Based on previous discussions about this topic, our understanding is that freezing the present ABI would impose an excessive burden on other sanitizer developers and for unrelated platforms. Therefore, we propose adding a secondary stable ABI for our use and anyone else in the community seeking the same. We believe that we can define a stable ABI with minimal burden on the community, expecting only to keep existing tests running and implementing stubs when new features are added. We are okay with trading performance for stability with no impact for existing users of ASan while minimizing the maintenance burden for ASan maintainers. We wish to commit this functionality to the LLVM project to maintain it there. This new and stable ABI will abstract away the implementation details allowing new and novel approaches to ASan for developers, researchers and others.
## Details
Rather than adding a lot of conditional code to the LLVM instrumentation phase, which would incur excessive complexity and maintenance cost of adding conditional code into all places that emit a runtime call, we propose a “shim” layer which will map the unstable ABI to the stable ABI:
* A static library (.a library) shim that maps the existing ASan ABI to a generalized, smaller and stable ABI. The library would implement the __asan functions and call into the new ABI. For example:
* `void __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); }`
* `void __asan_load2(uptr p) { __asan_abi_loadn(p, 2, true); }`
* `void __asan_noabort_load16(uptr p) { __asan_abi_loadn(p, 16, false); }`
* `void __asan_poison_cxx_array_cookie(uptr p) { __asan_abi_pac(p); }`
* This “shim” library would only be used by people who opt in: A compilation flag in the Clang driver will be used to gate the use of the stable ABI workflow.
* Utilize the existing ability for the ASan instrumentation to prefer runtime calls instead of inlined direct shadow memory accesses.
* Pursue (under the new driver flag) a better separation of abstraction and implementation with:
* LLVM instrumentation: Calling out for all poisoning, checking and unpoisoning.
* Runtime: Implementing the stable ABI and being responsible of implementation details of the shadow memory.
## Maintenance
Our aim is that the maintenance burden on the sanitizer developer community be negligible. Stable ABI tests will always pass for non-Darwin platforms. Changes to the existing ABI which would require a change to the shim have been infrequent as the ASan ABI is already relatively stable. Rarely, a change that impacts the contract between LLVM and the shim will occur. Among such foreseeable changes are: 1) changes to a function signature, 2) additions of new functions, or 3) deprecation of an existing function. Following are some examples of reasonable responses to those changes:
* Example: An existing ABI function is changed to return the input parameter on success or NULL on failure. In this scenario, a reasonable change to the shim would be to modify the function signature appropriately and to simply guess at a common-sense implementation.
* `uptr __asan_load1(uptr p) { __asan_abi_loadn(p, 1, true); return p; }`
* Example: An additional function is added for performance reasons. It has a very similar function signature to other similarly named functions and logically is an extension of that same pattern. In this case it would make sense to apply the same logic as the existing entry points:
* `void __asan_load128(uptr p) { __asan_abi_loadn(p, 128, true); }`
* Example: An entry point is added to the existing ABI for which there is no obvious stable ABI implementation: In this case, doing nothing in a no-op stub would be acceptable, assuming existing features of ASan can still work without an actual implementation of this new function.
* `void __asan_prefetch(uptr p) { }`
* Example: An entrypoint in the existing ABI is deprecated and/or deleted:
* (Delete the entrypoint from the shim.)
We’re looking for buy-in for this level of support.
(Note: Upon acceptance of the general concepts herein, we will add a controlling clang flag, cmake integration, contract for the stable ABI, and the appropriate test infrastructure.)
Reviewed By: eugenis, vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D143675
The copy must made according to the actual type, not the dummy type. In
case the dummy is polymorphic, these types will be different and the
dynamic type of the copy passed in the call should be the one of the
actual.
There is no support for "class(t), value" yet (it is hitting a TODO in
CallInterface that is moot for HLFIR but has not been lifted for lack of
proper testing) so the bug was dormant, but D151271 created a situation
where a copy is needed with polymorphic dummies and exposed the bug.
This led to a compile time assert
"value.isScalar() && fir::isa_trivial(value.getType())" in "hlfir::genAssociateExpr".
Differential Revision: https://reviews.llvm.org/D151413
!make.implicit metadata attached to branch means it will very likely
be eliminated (together with associated cmp instruction).
Reviewed By: apilipenko
Differential Revision: https://reviews.llvm.org/D149747
release_to_os has been failing on powerpc64 since yesterday. Temporarily disabling the test to prevent this error from
hiding other potential problems.
This patch adds an overload for the `map_to_vector` helper template, exposing a parameter to control the size of the resulting `SmallVector`. A few call sites in mlir are updated to illustrate and test the change.
Differential Revision: https://reviews.llvm.org/D150601
As pointed out in
https://discourse.llvm.org/t/undeterministic-thin-index-file/69985, the
block count added to distributed ThinLTO index files breaks incremental
builds on ThinLTO - if any linked file has a different number of BBs,
then the accumulated sum placed in the index files will change, causing
all ThinLTO backend compiles to be redone.
This was only used for partial sample profiles, and was therefore
removed for other cases (3adc6e03080c6d38a51f5c5b6744b7c0d9c7541b).
Subsequent testing did not show a performance effect of disabling this
feature even for partial sample profiles. Therefore, switch the default
to false. If this does not cause a noticeable performance degradation
after the default flip, we can remove this support completely.
Differential Revision: https://reviews.llvm.org/D151249
CPU profile indicated memcmp was hot due to the two rfind calls in
getCanonicalFnName. If UseSymbolTable is false, we can avoid the cost entirely.
For CSSPGO profiles I've measured ~5% speedup with this change.
Profile similarity before/after matches 100%.
Reviewed By: wenlei
Differential Revision: https://reviews.llvm.org/D151441
Add overloads of sshl_ov, ushl_ov, sshl_sat and ushl_sat that take the
shift amount as unsigned instead of APInt. This matches what we do for
the normal shift operators and can help to avoid creating temporary
APInts in some cases.
Differential Revision: https://reviews.llvm.org/D151420
@Mordante noticed that this was missing while making `<format>` non-experimental.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits, Mordante
Differential Revision: https://reviews.llvm.org/D151240
Note that the builders are protected by is64Bit().
More fine-grained availibility checks.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D150790
The x86-64 medium code model utilizes large data sections, namely .lrodata,
.lbss, and .ldata (along with some variants of .ldata). There is a proposal to
extend the use of large data sections to the large code model as well[1].
This patch aims to place large data sections away from code sections in order to
alleviate relocation overflow pressure caused by code sections referencing
regular data sections.
```
.lrodata
.rodata
.text # if --ro-segment, MAXPAGESIZE alignment
RELRO # MAXPAGESIZE alignment
.data # MAXPAGESIZE alignment
.bss
.ldata # MAXPAGESIZE alignment
.lbss
```
In comparison to GNU ld, which places .lbss, .lrodata, and .ldata after .bss, we
place .lrodata above .rodata to minimize the number of permission transitions in
the memory image.
While GNU ld places .lbss after .bss, the subsequent sections don't reuse the
file offset bytes of BSS.
Our approach is to place .ldata and .lbss after .bss and create a PT_LOAD
segment for .bss to large data section transition in the absence of SECTIONS
commands. assignFileOffsets ensures we insert an alignment instead of allocating
space for BSS, and therefore we don't waste more than MAXPAGESIZE bytes. We have
a missing optimization to prevent all waste, but implementing it would introduce
complexity and likely be error-prone.
GNU ld's layout introduces 2 more MAXPAGESIZE alignments while ours
introduces just one.
[1]: https://groups.google.com/g/x86-64-abi/c/jnQdJeabxiU "Large data sections for the large code model"
With help from Arthur Eubanks.
Co-authored-by: James Y Knight <jyknight@google.com>
Reviewed By: aeubanks, tkoeppe
Differential Revision: https://reviews.llvm.org/D150510
When the worklist is initially being formed, there is no need to
consider all nodes for pruning. This is because the first time calling
getNextWorklistEntry will only clear those nodes which have no uses,
with their operands being added to the worklist. However, when the worklist is
created for the first time all nodes are added anyways, so this operation
actually ends up adding no nodes.
This patch adds a parameter IsCandidateForPruning to AddToWorklist with a
default value of true to avoid having to update every call site.
Differential Revision: https://reviews.llvm.org/D151416
