Currently, there's a single flag, checked by the pass itself.
It can't force-enable the pass (and is on by default), because it
might not even have been created, as that's the targets decision.
Instead, have separate explicit flags, so that the decision is
consistently made in the target.
Keep the flag as a last-resort "force-disable GlobalMerge" for now,
for backwards compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234666 91177308-0d34-0410-b5e6-96231b3b80d8
The spilled registers are pristine and thus, correctly handled by
the register scavenger and so on, but the liveness information is
strictly speaking wrong at this point.
Fix that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234664 91177308-0d34-0410-b5e6-96231b3b80d8
This allows winehprepare to build sensible llvm.eh.actions calls for SEH
finally blocks. The pattern matching in this change is brittle and
should be replaced with something more robust soon. In the meantime,
this will let us write the code that produces __C_specific_handler xdata
tables, which we need regardless of how we decide to get finally blocks
through EH preparation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234663 91177308-0d34-0410-b5e6-96231b3b80d8
When rewriting statepoints to make relocations explicit, we need to have a conservative but consistent notion of where a particular pointer is live at a particular site. The old code just used dominance, which is correct, but decidedly more conservative then it needed to be. This patch implements a simple dataflow algorithm that's run one per function (well, twice counting fixup after base pointer insertion). There's still lots of room to make this faster, but it's fast enough for all practical purposes today.
Differential Revision: http://reviews.llvm.org/D8674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234657 91177308-0d34-0410-b5e6-96231b3b80d8
r234638 chained another transform below which was tripping over the
deleted instruction. Use after free found by asan in many regression
tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234654 91177308-0d34-0410-b5e6-96231b3b80d8
After submitting 234651, I noticed I hadn't responded to a review comment by mjacob. This patch addresses that comment and fixes a Release only build problem due to an unused variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234653 91177308-0d34-0410-b5e6-96231b3b80d8
Two related small changes:
Various dominance based queries about liveness can get confused if we're talking about unreachable blocks. To avoid reasoning about such cases, just remove them before rewriting statepoints.
Remove single entry phis (likely left behind by LCSSA) to reduce the number of live values.
Both of these are motivated by http://reviews.llvm.org/D8674 which will be submitted shortly.
Differential Revision: http://reviews.llvm.org/D8675
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234651 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds limited support for inserting explicit relocations when there's a vector of pointers live over the statepoint. This doesn't handle the case where the vector contains a mix of base and non-base pointers; that's future work.
The current implementation just scalarizes the vector over the gc.statepoint before doing the explicit rewrite. An alternate approach would be to plumb the vector all the way though the backend lowering, but doing that appears challenging. In particular, the size of the indirect spill slot is currently assumed to be sizeof(pointer) throughout the backend.
In practice, this is enough to allow running the SLP and Loop vectorizers before RewriteStatepointsForGC.
Differential Revision: http://reviews.llvm.org/D8671
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234647 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change moves creating calls to `llvm.uadd.with.overflow` from
InstCombine to CodeGenPrep. Combining overflow check patterns into
calls to the said intrinsic in InstCombine inhibits optimization because
it introduces an intrinsic call that not all other transforms and
analyses understand.
Depends on D8888.
Reviewers: majnemer, atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8889
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234638 91177308-0d34-0410-b5e6-96231b3b80d8
Stop leaking temporary nodes from `DIBuilder::createCompileUnit()`.
`replaceAllUsesWith()` doesn't delete the nodes, so we need to delete
them "manually" (well, `TempMDTuple` does that for us).
Similarly, stop leaking the temporary nodes used for variables of
subprograms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234617 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes some odd behavior differences between the two. In particular,
the version that takes a FD no longer unconditionally sets stdout to binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234615 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would always report success, which is pretty bogus.
I'm too lazy to write a test where rename will portably fail on all
platforms. I'm just trying to fix breakage introduced by r234597, which
happened to tickle this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234611 91177308-0d34-0410-b5e6-96231b3b80d8
WinEH currently turns invokes into calls. Long term, we will reconsider
this, but for now, make sure we remap the operands and clone the
successors of the new terminator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234608 91177308-0d34-0410-b5e6-96231b3b80d8
Iterating over loops from the LoopInfo instance only provides top-level loops.
We need to search the whole tree of loops to find the inner ones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234603 91177308-0d34-0410-b5e6-96231b3b80d8
CallSite roughly behaves as a common base CallInst and InvokeInst. Bring
the behavior closer to that model by making upcasts explicit. Downcasts
remain implicit and work as before.
Following dyn_cast as a mental model checking whether a Value *V isa
CallSite now looks like this:
if (auto CS = CallSite(V)) // think dyn_cast
instead of:
if (CallSite CS = V)
This is an extra token but I think it is slightly clearer. Making the
ctor explicit has the advantage of not accidentally creating nullptr
CallSites, e.g. when you pass a Value * to a function taking a CallSite
argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234601 91177308-0d34-0410-b5e6-96231b3b80d8
Using SchedAliases is convenient and works well for latency and resource
lookup for instructions. However, this creates an entry in
AArch64WriteLatencyTable with a WriteResourceID of 0, breaking any
SchedReadAdvance since the lookup will fail.
http://reviews.llvm.org/D8043
Patch by Dave Estes <cestes@codeaurora.org>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234594 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some optimizations such as jump threading and loop unswitching can negatively
affect performance when applied to divergent branches. The divergence analysis
added in this patch conservatively estimates which branches in a GPU program
can diverge. This information can then help LLVM to run certain optimizations
selectively.
Test Plan: test/Analysis/DivergenceAnalysis/NVPTX/diverge.ll
Reviewers: resistor, hfinkel, eliben, meheff, jholewinski
Subscribers: broune, bjarke.roune, madhur13490, tstellarAMD, dberlin, echristo, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8576
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234567 91177308-0d34-0410-b5e6-96231b3b80d8
The IPToState table must be emitted after we have generated labels for
all functions in the table. Don't rely on the order of the list of
globals. Instead, utilize WinEHFuncInfo to tell us how many catch
handlers we expect to outline. Once we know we've visited all the catch
handlers, emit the cppxdata.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234566 91177308-0d34-0410-b5e6-96231b3b80d8
When we have an instruction for this (and, thus, don't generate a runtime
call), we need to custom type legalize this (in a trivial way, just as we do
for fp_to_sint).
Fixes PR23173.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234561 91177308-0d34-0410-b5e6-96231b3b80d8
For the most common ones (such as fadd), we already did the promotion.
Do the same thing for all the others.
Currently, we'll just crash/assert on all these operations, as
there's no hardware or libcall support whatsoever.
f16 (half) is specified as an interchange - not arithmetic - format,
and is expected to be promoted to single-precision for arithmetic
operations.
While there, teach the legalizer about promoting some of the (mostly
floating-point) operations that we never needed before.
Differential Revision: http://reviews.llvm.org/D8648
See related discussion on the thread for: http://reviews.llvm.org/D8755
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234550 91177308-0d34-0410-b5e6-96231b3b80d8
formatted_raw_ostream is a wrapper over another stream to add column and line
number tracking.
It is used only for asm printing.
This patch moves the its creation down to where we know we are printing
assembly. This has the following advantages:
* Simpler lifetime management: std::unique_ptr
* We don't compute column and line number of object files :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234535 91177308-0d34-0410-b5e6-96231b3b80d8
We already do:
concat_vectors(scalar, undef) -> scalar_to_vector(scalar)
When the scalar is legal.
When it's not, but is a truncated legal scalar, we can also do:
concat_vectors(trunc(scalar), undef) -> scalar_to_vector(scalar)
Which is equivalent, since the upper lanes are undef anyway.
While there, teach the combine to look at more than 2 operands.
Differential Revision: http://reviews.llvm.org/D8883
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234530 91177308-0d34-0410-b5e6-96231b3b80d8
The integer extend optimization tries to fold the extend into the load
instruction. This requires us to identify if the extend has already been
emitted or not and act accordingly on it.
The check that was originally performed for this was not sufficient. Besides
checking the ValueMap for a mapped register we also need to check if the
virtual register has already an associated machine instruction that defines it.
This fixes rdar://problem/20470788.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234529 91177308-0d34-0410-b5e6-96231b3b80d8
Using this instead of
namespace llvm {
func...
}
Has the advantage that the build fails with a compiler error if it gets out
of sync with the .h file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234515 91177308-0d34-0410-b5e6-96231b3b80d8
Pull the `-preserve-*-use-list-order` flags out of "experimental" mode,
and preserve use-list order by default when serializing to bitcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234510 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Add classof implementations to the raw_ostream classes."
Revert "Use the cast machinery to remove dummy uses of formatted_raw_ostream."
The underlying issue can be fixed without classof.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234495 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, llvm (backend) doesn't know cortex-r4, even though it is the
default target for armv7r. Using "--target=armv7r-arm-none-eabi" provokes
'cortex-r4' is not a recognized processor for this target' by llvm.
This patch adds support for cortex-r4 and, very closely related, r4f.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234486 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Make the code more readable by fusing the for-loops together and explicitly checking for each register class.
Also, this version is more straightforward because it doesn't assume that FPU registers always come before CPU registers in the CalleeSavedInfo vector.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8033
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234475 91177308-0d34-0410-b5e6-96231b3b80d8
restrictions when choosing a type for small-memcpy inlining in
SelectionDAGBuilder.
This ensures that the loads and stores output for the memcpy won't be further
expanded during legalization, which would cause the total number of instructions
for the memcpy to exceed (often significantly) the inlining thresholds.
<rdar://problem/17829180>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234462 91177308-0d34-0410-b5e6-96231b3b80d8
If we know we are producing an object, we don't need to wrap the stream
in a formatted_raw_ostream anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234461 91177308-0d34-0410-b5e6-96231b3b80d8
The input to compileOptimized is already optimized and internalized, so remove
internalize pass from compileOptimized.
rdar://20227235
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234446 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed insert point for allocas created for demoted values.
Clear the nested landing pad list after it has been processed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234433 91177308-0d34-0410-b5e6-96231b3b80d8
The bug manifests when there are two loads and two stores chained as follows in
a DAG,
(ld v3f32) -> (st f32) -> (ld v3f32) -> (st f32)
and the stores' values are extracted from the preceding vector loads.
MergeConsecutiveStores would replace the first store in the chain with the
merged vector store, which would create a cycle between the merged store node
and the last load node that appears in the chain.
This commits fixes the bug by replacing the last store in the chain instead.
rdar://problem/20275084
Differential Revision: http://reviews.llvm.org/D8849
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234430 91177308-0d34-0410-b5e6-96231b3b80d8
The code uses a priority queue and a worklist, which share the same
visited set, but the visited set is only updated when inserting into
the priority queue. Instead, switch to using separate visited sets
for the priority queue and worklist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234425 91177308-0d34-0410-b5e6-96231b3b80d8
(Re-apply r234361 with a fix and a testcase for PR23157)
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.
Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).
In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.
When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).
The changes also adds support to query this property of the loop and
modify the vectorizer to use this.
Patch by Ashutosh Nema!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234424 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Even though there is no 2nd register operand in the "lw/sw $8, symbol" case, we still try to find one,
and we end up with $0, which makes us generate an unnecessary "addu $8, $8, $0" (a.k.a. "move $8, $8").
We can avoid this by checking if the 2nd register operand is different from $0, before generating the addu.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8055
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234406 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
They are of the form "bnezl/beqzl $rs, offset" and expand to "bnel/beql $rs, $zero, offset".
These instructions are used in Linux inline assembly.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8540
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234401 91177308-0d34-0410-b5e6-96231b3b80d8
One could make the argument for writing it immediately after the ELF header,
but writing it in the middle of the sections like we were doing just makes
it harder for no reason.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234400 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Looks like new code from [[ http://reviews.llvm.org/rL222057 | rL222057 ]] doesn't account for early `return` in `ARMFrameLowering::emitPrologue`, which leads to loosing `.cfi_def_cfa_offset` directive for functions without stack frame.
Reviewers: echristo, rengolin, asl, t.p.northover
Reviewed By: t.p.northover
Subscribers: llvm-commits, rengolin, aemerson
Differential Revision: http://reviews.llvm.org/D8606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234399 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These AssemblerPredicate's are unnecessary and actually make some instructions unusable when assembling pre-MIPS32 ISAs.
For example, this was causing the IAS to reject the 'j' instruction for MIPS I-V.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8300
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234398 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds an enum `OverflowCheckFlavor` and a function
`OptimizeOverflowCheck`. This will allow InstCombine to optimize
overflow checks without directly introducing an intermediate call to the
`llvm.$op.with.overflow` instrinsics.
This specific change is a refactoring and does not intend to change
behavior.
Reviewers: majnemer, atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8888
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234388 91177308-0d34-0410-b5e6-96231b3b80d8
If two livesegments from different subranges happened to have the same
definition they could possibly end up as two adjacent segments in the
main liverange with the same value number which is not allowed. Detect
such cases and fix them in the 2nd pass of computeFromMainRange() if
necessary.
No testcase as there is only an out-of-tree target where I can sensibly
come up with one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234382 91177308-0d34-0410-b5e6-96231b3b80d8
This is currently considered experimental, but most of the more
commonly used instructions should work.
So far only SI has been extensively tested, CI and VI probably work too,
but may be buggy. The current set of tests cases do not give complete
coverage, but I think it is sufficient for an experimental assembler.
See the documentation in R600Usage for more information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234381 91177308-0d34-0410-b5e6-96231b3b80d8
We weren't checking the sign of the floating point immediate before translating
it to "fmov sD, wzr". Similarly for D-regs.
Technically "movi vD.2s, #0x80, lsl #24" would work most of the time, but it's
not a blessed alias (and I don't think it should be since people expect writing
sD to zero out the high lanes, and there's no dD equivalent). So an error it is.
rdar://20455398
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234372 91177308-0d34-0410-b5e6-96231b3b80d8
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.
Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).
In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.
When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).
The changes also adds support to query this property of the loop and
modify the vectorizer to use this.
Patch by Ashutosh Nema!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234361 91177308-0d34-0410-b5e6-96231b3b80d8
The current crash reporting on Mac OS is only disabled via an environment variable.
This adds a boolean (default false) which can also disable crash reporting.
The only client right now is the unittests which don't ever want crash reporting, but do want to detect killed programs.
Reduces the time to run the APFloat unittests on my machine from
[----------] 47 tests from APFloatTest (51250 ms total)
to
[----------] 47 tests from APFloatTest (765 ms total)
Reviewed by Reid Kleckner and Justin Bogner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234353 91177308-0d34-0410-b5e6-96231b3b80d8
This shouldn't affect anything in-tree, as the OperandType users are
mostly smart disassemblers and such; more information is helpful there.
However, on the flip side, that + the fact that this is just hinting at
the meaning of operands makes this not really test-worthy or testable.
Differential Revision: http://reviews.llvm.org/D8620
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234350 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r234295 (and r234294 and r234292 before it). I
removed the implicit conversion to `MDTuple*` r234326, so there's no
longer an ambiguity in `operator[]()`.
I think MSVC should accept the original code now...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234335 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of lowering SELECT to SELECT_CC which is further lowered later
immediately call the SELECT_CC lowering code. This is preferable
because:
- Avoids an unnecessary roundtrip through the legalization queues with
an intermediate node.
- More importantly: Lowered operations get visited last leading to SELECT_CC
getting visited with legalized operands and unlegalized ones for preexisting
SELECT_CC nodes. This does not hurt the current code (hence no testcase) but
is required for another patch I am working on.
Differential Revision: http://reviews.llvm.org/D8187
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234334 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r234329, which insufficiently appeased older
`clang`s (apparently that wasn't the only call site). r234331 was a
more complete fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234333 91177308-0d34-0410-b5e6-96231b3b80d8
There were four almost identical implementations of calculating/updating
the register pressure for a certain MachineInstr. Cleanup to have a
single implementation (well, controlled with two bool flags until this
is cleaned up more).
No functional changes intended.
Tested by verify that there are no binary changes in the entire llvm
test-suite. A new test was added separately in r234309 as it revealed a
pre-existing error in the register pressure calculation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234325 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is not possible when using the IAS for MIPS, but it is possible when using the IAS for other architectures and when using GAS for MIPS.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8578
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234316 91177308-0d34-0410-b5e6-96231b3b80d8
This also moves it earlier so that it they are produced before we print
an end symbol for the data section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234315 91177308-0d34-0410-b5e6-96231b3b80d8
ensure that section addresses are distinct.
mapSectionAddress will fail if two sections are allocated the same address,
which can happen if any section has zero size (since malloc(0) is implementation
defined). Unfortunately I've been unable to repro this with a simple test case.
Fixes <rdar://problem/20314015>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234299 91177308-0d34-0410-b5e6-96231b3b80d8
Replace all uses of `DITypedArray<>` with `MDTupleTypedArrayWrapper<>`
and `MDTypeRefArray`. The APIs are completely different, but the
provided functionality is the same: treat an `MDTuple` as if it's an
array of a particular element type.
To simplify this patch a bit, I've temporarily typedef'ed
`DebugNodeArray` to `DIArray` and `MDTypeRefArray` to `DITypeArray`.
I've also temporarily conditionalized the accessors to check for null --
eventually these should be changed to asserts and the callers should
check for null themselves.
There's a tiny accompanying patch to clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234290 91177308-0d34-0410-b5e6-96231b3b80d8
Change `DIBuilder` to mutate `MDCompositeTypeBase` directly, and remove
the wrapping API in `DICompositeType`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234289 91177308-0d34-0410-b5e6-96231b3b80d8
Remove special iterators from `DIExpression` in favour of same in
`MDExpression`. There should be no functionality change here.
Note that the APIs are slightly different: `getArg(unsigned)` counts
from 0, not 1, in the `MDExpression` version of the iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234285 91177308-0d34-0410-b5e6-96231b3b80d8
During initial review, the `lo:` field was renamed to `lowerBound:`.
Make the same change to the C++ API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234267 91177308-0d34-0410-b5e6-96231b3b80d8
`DIDescriptor`'s subclasses allow construction from incompatible
pointers, and `DIDescriptor` defines a series of `isa<>`-like functions
(e.g., `isCompileUnit()` instead of `isa<MDCompileUnit>()`) that clients
tend to use like this:
if (DICompileUnit(N).isCompileUnit())
foo(DICompileUnit(N));
These construction patterns work together to make `DIDescriptor` behave
differently from normal pointers.
Instead, use built-in `isa<>`, `dyn_cast<>`, etc., and only build
`DIDescriptor`s from pointers that are valid for their type.
I've split this into a few commits for different parts of LLVM and clang
(to decrease the patch size and increase the chance of review).
Generally the changes I made were NFC, but in a few places I made things
stricter if it made sense from the surrounded code.
Eventually a follow-up commit will remove the API for the "old" way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234255 91177308-0d34-0410-b5e6-96231b3b80d8
Fast isel used to zero extends immediates to 64 bits. This normally goes
unnoticed because the value is truncated to 32 bits for output.
Two cases were it is noticed:
* We fail to use smaller encodings.
* If the original constant was smaller than i32.
In the tests using i1 constants, codegen would change to use -1, which is fine
(and matches what regular isel does) since only the lowest bit is then used.
Instead, this patch then changes the ir to use i8 constants, which looks more
like what clang produces.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234249 91177308-0d34-0410-b5e6-96231b3b80d8
Gut `DIRef<>::resolve()`, reimplementing it using
`TypedDebugNodeRef<>::resolve()`. Use three separate functions rather
than some sort of type traits, since the latter (i.e., mapping `DIScope`
=> `MDScope`) seems heavy-handed. I don't expect `DIRef<>` to last much
longer in tree anyway.
As a drive-by fix, make `TypedDebugNodeRef<>::resolve()` do the right
thing with `nullptr`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234248 91177308-0d34-0410-b5e6-96231b3b80d8
Remove `DILexicalBlockFile::getScope()` (whose last use was removed from
clang in r234245), which illegally returned a `DILexicalBlock` despite
its scope sometimes being an `MDSubprogram`. Also remove the
`getLineNumber()` and `getColumnNumber()` methods that just forwarded to
`DILexicalBlock`'s versions, since there don't seem to be any callers.
Note that the block of code removed from `DebugInfo.cpp` was actually
dead code, since `isLexicalBlock()` (the previous branch) always returns
true when `isLexicalBlockFile()` returns true.
An earlier (broken and untested) version of this was squashed into
r234222 and reverted in r234225.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234246 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of making a local copy of `checkInterfaceFunction` for each
sanitizer, move the function in a common place.
Reviewers: kcc, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8775
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234220 91177308-0d34-0410-b5e6-96231b3b80d8
A few calls are left in for error checking - but I'm commenting those
out & trying to build some IR tests (aiming for Argument Promotion to
start with). When I get any of these tests passing I may add flag to
disable the checking so I can add tests that pass with the assertion in
place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234206 91177308-0d34-0410-b5e6-96231b3b80d8
Remove `DIDescriptor::Verify()` and the `Verify()`s from subclasses.
They had already been gutted, and just did an `isa<>` check.
In a couple of cases I've temporarily dropped the check entirely, but
subsequent commits are going to disallow conversions to the
`DIDescriptor`s directly from `MDNode`, so the checks will come back in
another form soon enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234201 91177308-0d34-0410-b5e6-96231b3b80d8
Use `MDTypeRef` (etc.) in the new debug info hierarchy rather than raw
`Metadata *` pointers.
I rolled in a change to `DIBuilder` that looks unrelated: take `DIType`
instead of `DITypeRef` as type arguments when creating variables.
However, this was the simplest way to use `MDTypeRef` within the
functions, and didn't require any cleanups from callers in clang (since
they were all passing in `DIType`s anyway, relying on their implicit
conversions to `DITypeRef`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234197 91177308-0d34-0410-b5e6-96231b3b80d8
The uselist isn't enough to infer anything about the lifetime of such
allocas. If we want to re-add this optimization, we will need to
leverage lifetime markers to do it.
Fixes PR23122.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234196 91177308-0d34-0410-b5e6-96231b3b80d8
After recognising that a certain narrow instruction might need a relocation to
be represented, we used to unconditionally relax it to a Thumb2 instruction to
permit this. Unfortunately, some CPUs (e.g. v6m) don't even have most Thumb2
instructions, so we end up emitting a completely invalid instruction.
Theoretically, ELF does have relocations for these situations; but they are
fairly unusable with such short ranges and the ABI document even says they're
documented "for completeness". So an error is probably better there too.
rdar://20391953
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234195 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows SSE4.1 targets to use (V)PINSRB to create 16i8 vectors by inserting i8 scalars directly into a XMM register instead of merging pairs of i8 scalars into a i16 and using the SSE2 PINSRW instruction.
This allows folding of byte loads and reduces scalar register usage as well.
Differential Revision: http://reviews.llvm.org/D8839
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234193 91177308-0d34-0410-b5e6-96231b3b80d8
Add `MDTupleTypedArrayWrapper`, a wrapper around `MDTuple` that adapts
it to look like an array and cast its operands to the given type. This
is designed to be a replacement for `DITypedArray<>`, which is in the
`DIDescriptor` hierarchy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234183 91177308-0d34-0410-b5e6-96231b3b80d8
Most fields are now accessed via the new debug info hierarchy. I'll
make the rest of this code dead soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234182 91177308-0d34-0410-b5e6-96231b3b80d8
This upgrade of `@llvm.dbg.declare` and `@llvm.dbg.value` isn't useful,
since it's for an old debug info version. The calls will get stripped
anyway by `UpgradeDebugInfo()`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234181 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing checks for `templateParams:` in `MDCompositeType`. Pull the
current check for `MDSubprogram` to reduce duplicated code and fix it up
to print a good message when the immediate operand isn't an `MDTuple`
(as a drive-by, make the same fix to `variables:` in `MDSubprogram`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234177 91177308-0d34-0410-b5e6-96231b3b80d8
H.J. Lu noted that all .section options are separated by a comma.
This patch changes the syntax of unique to require one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234174 91177308-0d34-0410-b5e6-96231b3b80d8
As pr19627 points out, every use of AliasedSymbol is likely a bug.
The main use was to avoid the oddity of a variable showing up as undefined. That
was fixed in r233995, which made these calls nops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234169 91177308-0d34-0410-b5e6-96231b3b80d8
Before when deciding if we needed a relocation in A-B, we wore only checking
if A was weak.
This fixes the asymmetry.
The "InSet" argument should probably be renamed to "ForValue", since InSet is
very MachO specific, but doing so in this patch would make it hard to read.
This fixes PR22815.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234165 91177308-0d34-0410-b5e6-96231b3b80d8
The case values are not a tidy enum we can fully cover. They even ovelap
over the various extension.
Just use a default:
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234140 91177308-0d34-0410-b5e6-96231b3b80d8
Just store the section in MCSectionELF. This avoids multiple hash lookups.
This will also be used by ARM_EXIDX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234139 91177308-0d34-0410-b5e6-96231b3b80d8
There's still lots of callers passing nullptr, of course - some because
they'll never be migrated (InstCombines for bitcasts - well they don't
make any sense when the pointer type is opaque anyway, for example) and
others that will need more engineering to pass Types around.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234126 91177308-0d34-0410-b5e6-96231b3b80d8