Convert analyzeContextInfo to a work list using the same approach I used
to remove the recursion from lookForDIEsToKeep. This fixes the crash
reported in https://llvm.org/PR48029.
Tested using the reproducer attached to PR48029 as well as by comparing
the clang MD5 hashes before and after the change (with and without
gmodules).
Differential revision: https://reviews.llvm.org/D90873
The distinction between StructOffset and OtherOffset has been
originally introduced by 82069c44ca39df9d506e16bfb0ca2481866dd0bb,
which applied different reasoning to both offset kinds. However,
this distinction was not actually correct, and has been fixed by
c84e77aeaefccb8d0c4c508b8017dcad80607f53. Since then, we only ever
consider the sum StructOffset + OtherOffset, so we may as well
store it in that form directly.
Instead of performing the multiplication in double the bit width
and using active bits to determine overflow, use the existing
smul_ov() APInt method to detect overflow.
The smul_ov() implementation is not particularly efficient, but
it's still better than doing this a wide, usually 128-bit, type.
If there are too many uses, we should directly return -- there's
no point in inspecting the remaining uses in the worklist, as we
have to conservatively assume a capture anyway. This also means
that tooManyUses() gets called exactly once, rather than
potentially many times.
This restores the behavior prior to e9832dfdf366ddffba68164adb6855d17c9f87c1,
where this was accidentally changed while moving the AddUses logic
into a closure, thus making the return a return from the closure
rather than the whole function.
If the same value is used multiple times in the same instruction,
CaptureTracking may end up reporting the wrong use as being captured,
and/or report the same use as being captured multiple times.
Make sure that all checks take the use operand number into account,
rather than performing unreliable comparisons against the used value.
I'm not sure whether this can cause any problems in practice, but
at least some capture trackers (ArgUsesTracker, AACaptureUseTracker)
do care about which call argument is captured.
The patch simplifies BranchProbabilityInfo::getEdgeProbability by
handling two cases separately, depending on whether we have edge
probabilities.
- If we have edge probabilities, then add up probabilities for
successors being equal to Dst.
- Otherwise, return the number of ocurrences divided by the total
number of successors.
Differential Revision: https://reviews.llvm.org/D90980
Eliminate the need to go through the DIE index by passing the DIE to
CompileUnit::getInfo directly.
Before:
unsigned Idx = Unit->getOrigUnit().getDIEIndex(Die);
CompileUnit::DIEInfo &Info = Unit->getInfo(Idx);
After:
CompileUnit::DIEInfo &Info = Unit->getInfo(Die);
From C11 and C++11 onwards, a forward-progress requirement has been
introduced for both languages. In the case of C, loops with non-constant
conditionals that do not have any observable side-effects (as defined by
6.8.5p6) can be assumed by the implementation to terminate, and in the
case of C++, this assumption extends to all functions. The clang
frontend will emit the `mustprogress` function attribute for C++
functions (D86233, D85393, D86841) and emit the loop metadata
`llvm.loop.mustprogress` for every loop in C11 or later that has a
non-constant conditional.
This patch modifies LoopDeletion so that only loops with
the `llvm.loop.mustprogress` metadata or loops contained in functions
that are required to make progress (`mustprogress` or `willreturn`) are
checked for observable side-effects. If these loops do not have an
observable side-effect, then we delete them.
Loops without observable side-effects that do not satisfy the above
conditions will not be deleted.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D86844
When inlining `mustprogress` functions, if the caller or the callee has
the attribute, we drop the function attribute. The loops that have the
`llvm.loop.mustprogress` metadata keep their metadata. We do not need to
add new loop metadata to inlined functions because the patch in D86841
already adds the relevant loop metadata in all of the necessary places.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D87262
MASM interprets strings in expression contexts as integers expressed in big-endian base-256, treating each character as its ASCII representation.
This completely eliminates the need to special-case single-character strings.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D90788
Currently, LoopDeletion refuses to remove dead loops with no exit blocks
because it cannot statically determine the control flow after it removes
the block. This leads to miscompiles if the loop is an infinite loop and
should've been removed.
Differential Revision: https://reviews.llvm.org/D90115
Some binaries can contain regular sections with zero offset and zero size.
This diff makes llvm-objcopy's handling of such sections consistent with
cctools's strip (which doesn't modify them),
previously the tool would allocate file space for them.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D90796
YAML support allows us to better test the feature in the subsequent patches. The implementation is quite similar to the .stack_sizes section.
Reviewed By: jhenderson, grimar
Differential Revision: https://reviews.llvm.org/D88717
Makes sure that the unwind info uses 64bits pcrel relocation if a large code model is specified and handle the corresponding relocation in the ExecutionEngine. This can happen with certain kernel configuration (the same as the one in https://reviews.llvm.org/D27609, found at least on the ArchLinux stock kernel and the one used on https://www.packet.net/) using the builtin JIT memory manager.
Co-authored-by: Yichao Yu <yyc1992@gmail.com>
Differential Revision: https://reviews.llvm.org/D27629
Results of convergent operations are implicitly affected by the
enclosing control flows and should not be hoisted out of arbitrary
loops.
Patch by Xiaoqing Wu <xiaoqing_wu@apple.com>
Differential Revision: https://reviews.llvm.org/D90361
Avoid an expensive isKnownNonZero() call - this is a small cleanup before moving the extra NSW functionality from computeKnownBitsMul into KnownBits::computeForMul.
The strictfp metadata was added to the casting AST nodes in D85960, but
we aren't using that metadata yet. This patch adds that support.
In order to avoid lots of ad-hoc passing around of the strictfp bits I
updated the IRBuilder when moving from a function that has the Expr* to a
function that lacks it. I believe we should switch to this pattern to keep
the strictfp support from being overly invasive.
For the purpose of testing that we're picking up the right metadata, I
also made my tests use a pragma to make the AST's strictfp metadata not
match the global strictfp metadata. This exposes issues that we need to
deal with in subsequent patches, and I believe this is the right method
for most all of our clang strictfp tests.
Differential Revision: https://reviews.llvm.org/D88913
Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I have fixed
here.
Differential Revision: https://reviews.llvm.org/D90937
Treat any identifier as a potential exp target and diagnose them all the
same way as "invalid exp target"s.
Differential Revision: https://reviews.llvm.org/D90947
idiv: There is no difference between Armv7m and Thumbv7M
behaviour so the specific CHECKs are not needed.
The errors for Armv7-a and Thumbv7-a will always
include "ARM" or "THUMB" respectively so they need their
own CHECK prefix, making CHECK-V7 redundant.
mp: Behaviour is dependent on whether the triple is v6/v7/v7M
regardless of being Arm or Thumb. So we don't need the more
specific CHECK-ARMv7M etc.
simd: Errors are either v7 only, or v7 and v8 so CHECK-V8
is not needed.
fp: Same as simd
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D90918
The `llvm.coro.suspend.async` intrinsic takes a function pointer as its
argument that describes how-to restore the current continuation's
context from the context argument of the continuation function. Before
we assumed that the current context can be restored by loading from the
context arguments first pointer field (`first_arg->caller_context`).
This allows for defining suspension points that reuse the current
context for example.
Also:
llvm.coro.id.async lowering: Add llvm.coro.preprare.async intrinsic
Blocks inlining until after the async coroutine was split.
Also, change the async function pointer's context size position
struct async_function_pointer {
uint32_t relative_function_pointer_to_async_impl;
uint32_t context_size;
}
And make the position of the `async context` argument configurable. The
position is specified by the `llvm.coro.id.async` intrinsic.
rdar://70097093
Differential Revision: https://reviews.llvm.org/D90783
Prepare for supporting different calling conventions by factoring out
things into CC-dependent selection functions (getParamCC, getReturnCC).
Reviewed By: kaz7
Differential Revision: https://reviews.llvm.org/D90911
