| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 234430
|
| |
|
|
| |
llvm-svn: 234392
|
| |
|
|
| |
llvm-svn: 234385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same valno
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.
llvm-svn: 234382
|
| |
|
|
|
|
|
|
| |
to identify their personality.
Differential Review: http://reviews.llvm.org/D8835
llvm-svn: 234360
|
| |
|
|
|
|
|
|
| |
The lack of a catch object is indicated by a frame escape index of -1.
Fixes PR23137.
llvm-svn: 234346
|
| |
|
|
|
|
|
|
|
|
| |
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...
llvm-svn: 234335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234325
|
| |
|
|
|
|
|
| |
This also moves it earlier so that it they are produced before we print
an end symbol for the data section.
llvm-svn: 234315
|
| |
|
|
|
|
| |
This makes sure they are only output once (and frees a bit of memory).
llvm-svn: 234313
|
| |
|
|
| |
llvm-svn: 234310
|
| |
|
|
|
|
|
|
| |
I have no idea what MSVC means with its error text here :(.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2310
llvm-svn: 234295
|
| |
|
|
|
|
|
|
| |
Still failing:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2309
llvm-svn: 234294
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/2308
llvm-svn: 234292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234290
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234285
|
| |
|
|
|
|
| |
Same as r234255, but for lib/CodeGen and lib/Target.
llvm-svn: 234258
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234249
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234201
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234196
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8715
llvm-svn: 234179
|
| |
|
|
|
|
| |
NFCI.
llvm-svn: 234118
|
| |
|
|
| |
llvm-svn: 234108
|
| |
|
|
| |
llvm-svn: 234106
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows the compiler/assembly programmer to switch back to a
section. This in turn fixes the bootstrap failure on powerpc (tested
on gcc110) without changing the ppc codegen at all.
I will try to cleanup the various getELFSection overloads in a followup patch.
Just using a default argument now would lead to ambiguities.
llvm-svn: 234099
|
| |
|
|
|
|
|
|
| |
re-association
Scalar integers are commuted to move constants to the RHS for re-association - this ensures vectors do the same.
llvm-svn: 234092
|
| |
|
|
|
|
| |
Now all fields in the WinEH xdata have been filled out.
llvm-svn: 234067
|
| |
|
|
|
|
|
| |
This add support for catching an exception such that an exception object
available to the catch handler will be initialized by the runtime.
llvm-svn: 234062
|
| |
|
|
|
|
|
|
| |
We don't need to represent UnwindHelp in IR. Instead, we can use the
knowledge that we are emitting the parent function to decide if we
should create the UnwindHelp stack object.
llvm-svn: 234061
|
| |
|
|
| |
llvm-svn: 234059
|
| |
|
|
| |
llvm-svn: 234058
|
| |
|
|
| |
llvm-svn: 234045
|
| |
|
|
| |
llvm-svn: 234043
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8596
llvm-svn: 234041
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a follow-up to r234021, assert that a debug info intrinsic variable's
`MDLocalVariable::getInlinedAt()` always matches the
`MDLocation::getInlinedAt()` of its `!dbg` attachment.
The goal here is to get rid of `MDLocalVariable::getInlinedAt()`
entirely (PR22778), but I'll let these assertions bake for a while
first.
If you have an out-of-tree backend that just broke, you're probably
attaching the wrong `DebugLoc` to a `DBG_VALUE` instruction. The one
you want is the location that was attached to the corresponding
`@llvm.dbg.declare` or `@llvm.dbg.value` call that you started with.
llvm-svn: 234038
|
| |
|
|
| |
llvm-svn: 234034
|
| |
|
|
|
|
|
| |
Use `MDLocalVariable` and `MDExpression` directly for the arguments of
`EmitFuncArgumentDbgValue()` to simplify a follow-up patch.
llvm-svn: 234026
|
| |
|
|
|
|
|
| |
Grab the `MDLocalVariable` from the second-to-last argument; the last
argument is an `MDExpression`, and mixing them up will crash.
llvm-svn: 234019
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 234018
|
| |
|
|
|
|
|
|
| |
This patch attempts to fold the shuffling of 'scalar source' inputs - BUILD_VECTOR and SCALAR_TO_VECTOR nodes - if the shuffle node is the only user. This folds away a lot of unnecessary shuffle nodes, and allows quite a bit of constant folding that was being missed.
Differential Revision: http://reviews.llvm.org/D8516
llvm-svn: 234004
|
| |
|
|
| |
llvm-svn: 233978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to use the same representation of llvm.eh.actions
in outlined handlers as we use in the parent function because i32's are
just constants that can be copied freely between functions.
I had to add a sentinel alloca to the list of child allocas so that we
don't try to sink the catch object into the handler. Normally, one would
use nullptr for this kind of thing, but TinyPtrVector doesn't support
null elements. More than that, it's elements have to have a suitable
alignment. Therefore, I settled on this for my sentinel:
AllocaInst *getCatchObjectSentinel() {
return static_cast<AllocaInst *>(nullptr) + 1;
}
llvm-svn: 233947
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Require the pointee type to be passed explicitly and assert that it is
correct. For now it's possible to pass nullptr here (and I've done so in
a few places in this patch) but eventually that will be disallowed once
all clients have been updated or removed. It'll be a long road to get
all the way there... but if you have the cahnce to update your callers
to pass the type explicitly without depending on a pointer's element
type, that would be a good thing to do soon and a necessary thing to do
eventually.
llvm-svn: 233938
|
| |
|
|
|
|
| |
These two were never implemented for gcroot, so there's no point in keeping them around now.
llvm-svn: 233892
|
| |
|
|
|
|
|
|
|
| |
I'm playing with supporting custom stack map formats with statepoints. While
doing so, I noticed that the existing implementation didn't indicate inherently
unsized frames. This change essentially just ports the functionality that already
exists for the default StackMaps section to custom stackmaps.
llvm-svn: 233891
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8682
llvm-svn: 233824
|
| |
|
|
|
|
|
| |
A catch (...) doesn't have a type descriptor. Instead, the 'adjectives'
field has bit six set.
llvm-svn: 233788
|
| |
|
|
|
|
| |
scalar_to_vector.
llvm-svn: 233778
|
| |
|
|
|
|
| |
Remove a redundant condition, no functional change intended.
llvm-svn: 233770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us catch exceptions in simple cases.
N.B. Things that do not work include (but are not limited to):
- Throwing from within a catch handler.
- Catching an object with a named catch parameter.
- 'CatchHigh' is fictitious, we aren't sure of its purpose.
- We aren't entirely efficient with regards to the number of EH states
that we generate.
- IP-to-State tables are sensitive to the order of emission.
llvm-svn: 233767
|