The initial version was reverted because it looped infinitely if the likely successor
isn't properly dominated by the predecessor. In practice it means that we went up the
CFG through backedge and looped infinitely.
I also added some paranoid assertion checks to make sure that every other invariant
holds. I also found a hypothetical situation when we may go past the dominated block
while following the likely successors (it means that in fact the dominated block is
dynamically not reachable from dominating block) and explicitly prohibited this, though
I don't have a motivating test showing that it's a real problem.
https://reviews.llvm.org/D146276
The revision adds the handleArgument and handleResult handlers that
allow users of the inlining interface to implement argument and result
conversions that take argument and result attributes into account. The
motivating use cases for this revision are taken from the LLVM dialect
inliner, which has to copy arguments that are marked as byval and that
also has to consider zeroext / signext when converting integers.
All type conversions are currently handled by the
materializeCallConversion hook. It runs before isLegalToInline and
supports only the introduction of a single cast operation since it may
have to rollback. The new handlers run shortly before and after
inlining and cannot fail. As a result, they can introduce more complex
ir such as copying a struct argument. At the moment, the new hooks
cannot be used to perform type conversions since all type conversions
have to be done using the materializeCallConversion. A follow up
revision will either relax this constraint or drop
materializeCallConversion in favor of the new and more flexible
handlers.
The revision also extends the CallableOpInterface to provide access
to the argument and result attributes if available.
Reviewed By: rriddle, Dinistro
Differential Revision: https://reviews.llvm.org/D145582
Blocks are enumerated depth-first, but post-order. I.e., a block is enumerated when its successors have been enumerated. This iteration style is suitable when deleting blocks in a regions: in the absence of cycles, uses are deleted before their definitions.
Differential Revision: https://reviews.llvm.org/D146125
In the following example, we will end up hitting the `llvm_unreachable()`:
https://godbolt.org/z/5sccc95Ec
```lang=C++
enum class E {};
const E glob[] = {{}};
void initlistWithinInitlist() {
clang_analyzer_dump(glob[0]); // crashes at loading from `glob[0]`
}
```
We should just return `std::nullopt` instead for these cases.
It's better than crashing.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D146538
Plugin that counts the number of times each tree node occurs in a given program. Used for test coverage.
Updated to fix build issues.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D143704
All of these methods will invoke `getOrCreateSymbol(const Twine &Name)`, using `Twine` here makes these methods more flexible.
Differential Revision: https://reviews.llvm.org/D145923
Creating maximally folded and composd affine.apply operation during
FoldMemRefAliasOps composes better with other transformations without having
to interleave canonicalization passes.
Differential Revision: https://reviews.llvm.org/D146515
Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
When doing store constant vector/scalar, some duplicated values can be reused.
Add test case and will show combiner can improve these.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D146500
We custom isel for ConstantFP that has higher priority than isel
patterns. We were previously detecting valid FP constants for fli
to early exit from the custom code. This detection called
getLoadFPImm. Then we would run the isel patterns which would call
getLoadFPImm a second time.
With a little bit more code we can directly select the fli instruction
in the custom handler and avoid a second call.
Remove the incorrect mayRaiseFPException flag from the FLI instructions.
Reviewed By: joshua-arch1
Differential Revision: https://reviews.llvm.org/D146093
Note that the comments being removed appear to be very out of sync with the actual code in question.
Differential Revision: https://reviews.llvm.org/D146468
The shadow pointer map was problematic as we scanned an entire list if
an entry had shadow pointers. The new scheme stores the shadow pointers
inside the entries. This allows easy access without any search. It also
helps us, but also makes it necessary, to define a consistent locking
scheme. The implicit locking of entries via TargetPointerResultTy makes
this pretty effortless, however one has to:
- Lock HDTTMap before locking an entry.
- Do not lock HDTTMap while holding an entry lock.
- Hold the entry lock to read or modify an entry.
The changes to submitData and retrieveData have been made to ensure 2
when the LIBOMPTARGET_INFO flag is used. Most everything else happens by
itself as TargetPointerResultTy acts as a lock_guard for the entry. It
is a little complicated when we deal with multiple entries, especially
as they can be equal. However, one can still follow the rules with
reasonable effort.
LookupResult are now finally also locking the entry before it is
inspected. This is good even if we haven't run into a problem yet.
Differential Revision: https://reviews.llvm.org/D123446
This unblocks one of the XFAIL tests for AMD, though we need to work
around the missing printf still.
Differential Revision: https://reviews.llvm.org/D146592
Summary:
This startup code is only intended to be used internally, we shouldn't
export it under a conflicting name. In the future we may package this in
an exportable format.
The Zcb extension has c.lbu, but not c.lb. This patch makes us
prefer LBU over LB if we have a choice which will enable more
compression opportunities.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D146270
Non-plugin lldb libraries should generally not be linking against lldb
plugin libraries. Enforce this in CMake.
Differential Revision: https://reviews.llvm.org/D146553
The lower 2 bits of the opcode must be 0x3. If the lower 2 bits are
0-2, it's a compressed instruction.
Merge 3 slightly different error messages into 1 to reduce code. The
messages differed slightly depending on whether we parsed a string
or an expression. The message gets a little more generic, but is no
more generic than what binutils prints.
Fixes clang crash caused by a stale function pointer.
The bug has been present for a pretty long time, but we were lucky not to
trigger it until D140663.
Differential Revision: https://reviews.llvm.org/D146448
Move responsibility of providing the instance variable name (`this`, `self`) from
`TypeSystem` to `Language`.
`Language` the natural place for this, but also has downstream benefits. Some languages
have multiple `TypeSystem` implementations (ex Swift), and by placing this logic in the
`Language`, redundancy is avoided.
This change relies on the tests from D145348 and D146320.
Differential Revision: https://reviews.llvm.org/D146548
Some uses of TOSA rely on the constant operands of particular operations,
e.g. paddings and pad_const in pad op. Add a verification pattern in the
validation pass, and this is optionally enabled.
Change-Id: I1628c0840a27ab06ef91150eee56ad4f5ac9543d
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D145412
Support symolization of PIE binaries in memprof. We assume that the
profiled binary has one executable text segment for simplicity. Update
the memprof-pic test to now expect the same output as the memprof-basic test.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D146181
When we check for similarity, right now there is no order to how it is checked, except for via the suffix tree ordering.
We can reduce how much structural analysis we perform by checking the the regions in decreasing size. In doing so, we know that if two large sections match, each of their contained regions also match. This allows us to skip the structural checking for each smaller section. IT does require that we use the large regions as a "bridge" to create the canonical mapping between the two regions.
This reduces compile time significantly for some benchmarks. It will not perform as well for programs with many small items.
Recommit fixes the IRSimilarity tests.
Recommit of: 805ec19d7d
Recommit fixes llvm-sim tests
Recommit of: 082ec26758
Reviewer: paquette
Differential Revision: https://reviews.llvm.org/D139338
Take the source position for the anonymous program from its scope.
If the first evaluation is a construct or directive, then it has
null source position.
Author: vdonaldson
Differential Revision: https://reviews.llvm.org/D146445
Spinlock symbols are removed from headers in MacOS version 10.12 and greater.
Even though they are deprecated, the symbols remain available on the system.
The TSAN interceptors currently cause a build failure after this version because
of the change in availability of the symbol.
We want to continue intercepting the symbols available on the OS.
So we add forward declarations so that the TSAN interceptors can build.
This is tested with the existing osspinlock_norace test.
Differential Revision: https://reviews.llvm.org/D146537
