| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Add some accessors to `MDExpression`.
llvm-svn: 228648
|
| |
|
|
| |
llvm-svn: 228647
|
| |
|
|
| |
llvm-svn: 228645
|
| |
|
|
|
|
| |
Well, the exact error from the failed parse will change, but...
llvm-svn: 228644
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win64 has specific contraints on what valid prologues and epilogues look
like. This constraint is born from the flexibility and descriptiveness
of Win64's unwind opcodes.
Prologues previously emitted by LLVM could not be represented by the
unwind opcodes, preventing operations powered by stack unwinding to
successfully work.
Differential Revision: http://reviews.llvm.org/D7520
llvm-svn: 228641
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add specialized debug info metadata nodes that match the `DIDescriptor`
wrappers (used by `DIBuilder`) closely. Assembly and bitcode support to
follow soon (it'll mostly just be obvious), but this sketches in today's
schema. This is the first big commit (well, the only *big* one aside
from the testcase changes that'll come when I move this into place) for
PR22464.
I've marked a bunch of obvious changes as `TODO`s in the source; I plan
to make those changes promptly after this hierarchy is moved underneath
`DIDescriptor`, but for now I'm aiming mostly to match the status quo.
llvm-svn: 228640
|
| |
|
|
|
|
| |
preparation for making it MachineFunction dependent.
llvm-svn: 228638
|
| |
|
|
| |
llvm-svn: 228637
|
| |
|
|
| |
llvm-svn: 228635
|
| |
|
|
|
|
|
|
| |
I realized that my early fix for this was overly complicated. Rather than scatter checks around in a bunch of places, just exit early when we visit the poll function itself.
Thinking about it a bit, the whole inlining mechanism used with gc.safepoint_poll could probably be cleaned up a bit. Originally, poll insertion was fused with gc relocation rewriting. It might be worth going back to see if we can simplify the chain of events now that these two are seperated. As one thought, maybe it makes sense to rewrite calls inside the helper function before inlining it to the many callers. This would require us to visit the poll function before any other functions though..
llvm-svn: 228634
|
| |
|
|
|
|
| |
of RaiseException.
llvm-svn: 228633
|
| |
|
|
|
|
|
|
|
|
| |
for any padding introduced by SROA. In particular, do not emit debug info
for an alloca that represents only the padding introduced by a previous
iteration.
Fixes PR22495.
llvm-svn: 228632
|
| |
|
|
|
|
|
|
|
|
|
| |
intermediate representation. This
- increases consistency by using the same granularity everywhere
- allows for pieces < 1 byte
- DW_OP_piece didn't actually allow storing an offset.
Part of PR22495.
llvm-svn: 228631
|
| |
|
|
|
|
| |
parameter.
llvm-svn: 228630
|
| |
|
|
|
|
|
|
|
| |
I just realized that the specialized metadata node patch I'm about to
commit won't compile on old compilers. Bump `hash_combine()`'s support
for non-variadic templates to 18 (I tested this by reversing the logic
in the #ifdef).
llvm-svn: 228629
|
| |
|
|
|
|
| |
require (one which calls our vectored exception handler), and fall back to using a volatile write to simulate a trap elsewhere.
llvm-svn: 228628
|
| |
|
|
|
|
| |
unused ones.
llvm-svn: 228627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It's important that our users immediately know what gc.safepoint_poll
is. Also fix the style of the declaration of CreateGCStatepoint, in
preparation for another change that will wrap it.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7517
llvm-svn: 228626
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7516
llvm-svn: 228625
|
| |
|
|
|
|
|
|
| |
Remove handling for DW_TAG_constant. We started producing it in
r110656, but reverted that in r110876 without dropping the support.
Finish the job.
llvm-svn: 228623
|
| |
|
|
| |
llvm-svn: 228621
|
| |
|
|
| |
llvm-svn: 228620
|
| |
|
|
|
|
|
|
|
|
|
| |
`DIExpression` deals with `uint64_t`, so it doesn't make sense that
`createExpression()` is created from `int64_t`. Switch to `uint64_t` to
unify them.
I've temporarily left in the `int64_t` version, which forwards to the
`uint64_t` version. I'll delete it once I've updated the callers.
llvm-svn: 228619
|
| |
|
|
|
|
| |
These tests the two optimizations for backedge insertion currently implemented and the split backedge flag which is currently off by default.
llvm-svn: 228617
|
| |
|
|
|
|
| |
This reverts commit add62ac537d8249fa2161405066e318ca80e199d.
llvm-svn: 228616
|
| |
|
|
| |
llvm-svn: 228615
|
| |
|
|
| |
llvm-svn: 228614
|
| |
|
|
|
|
|
| |
a) add gc attribute
b) remove unused param
llvm-svn: 228612
|
| |
|
|
|
|
|
|
|
|
| |
Without a valid data layout, deferenceable(N) doesn't get parsed or
propagated. Since this is the key item we are testing, add a dependency
on the pass.
Differential Revision: http://reviews.llvm.org/D7508
llvm-svn: 228611
|
| |
|
|
|
|
| |
This is just adding really simple tests which should have been part of the original submission. When doing so, I discovered that I'd mistakenly removed required pieces when preparing the patch for upstream submission. I fixed two such bugs in this submission.
llvm-svn: 228610
|
| |
|
|
| |
llvm-svn: 228609
|
| |
|
|
|
|
|
| |
I'll circle back and fix this somehow; for now I just don't want to
forget about it.
llvm-svn: 228608
|
| |
|
|
|
|
| |
These are never referenced or filled in.
llvm-svn: 228607
|
| |
|
|
|
|
|
|
|
|
| |
While a theoretical GC might change dereferenceability on collection,
there is no such known collector and no need to account for the case
with a flag yet.
Differential Revision: http://reviews.llvm.org/D7454
llvm-svn: 228606
|
| |
|
|
| |
llvm-svn: 228605
|
| |
|
|
|
|
|
|
|
|
| |
5 minutes is an eternity, so try to strike a better balance between
waiting long enough for any reasonable module build and not so long that
users kill the process because they think it's hanging.
Also give the client a way to delete the lock file after a timeout.
llvm-svn: 228603
|
| |
|
|
| |
llvm-svn: 228602
|
| |
|
|
| |
llvm-svn: 228598
|
| |
|
|
|
|
|
|
|
| |
Make use of the newly introduced inst_range to clean up two loops. Clean
up a third one while at it.
Differential Revision: http://reviews.llvm.org/D7455
llvm-svn: 228596
|
| |
|
|
|
|
|
| |
<NW> bit of a SCEVAddRecExpr does not depend on the sign of the step
and the start value of the step.
llvm-svn: 228595
|
| |
|
|
| |
llvm-svn: 228593
|
| |
|
|
| |
llvm-svn: 228587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a scev for sext({X,+,Y}), scev checks if the expression
is equivalent to {sext X,+,zext Y}. If it can prove that, it also
tags the original {X,+,Y} as <nsw>, which is not correct.
In the test case I run `-scalar-evolution` twice because the bug
manifests only once SCEV has run through and seen the `sext`
expressions (and then does a in-place mutation on {X,+,Y}).
Differential Revision: http://reviews.llvm.org/D7495
llvm-svn: 228586
|
| |
|
|
|
|
|
| |
As far as I can tell r228568 was the right workaround, and r228567 was
unnecessary. If reverting this causes problems on the bots I'll reinstate it.
llvm-svn: 228585
|
| |
|
|
| |
llvm-svn: 228581
|
| |
|
|
|
|
|
|
|
|
|
|
| |
veqv (vector equivalence)
vnand
vorc
I increased the AddedComplexity for these instructions to 500 to ensure they are generated instead of issuing other VSX instructions.
Phabricator review: http://reviews.llvm.org/D7469
llvm-svn: 228580
|
| |
|
|
| |
llvm-svn: 228579
|
| |
|
|
| |
llvm-svn: 228578
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For the attached test case different types are used in the ICmpInst
and SelectInst that represent the min/max expressions. However, if the
ICmpInst type is smaller a comparison with the sign/zero extended
operands would have yielded the same result. This situation might
arise after the instruction combination pass was applied.
Differential Revision: http://reviews.llvm.org/D7338
llvm-svn: 228572
|
| |
|
|
| |
llvm-svn: 228568
|