| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 234586
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234566
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 234550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :-)
llvm-svn: 234535
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 234530
|
| |
|
|
|
|
| |
This reverts commit r234513. It was failing on the bots.
llvm-svn: 234518
|
| |
|
|
| |
llvm-svn: 234513
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 234495
|
| |
|
|
|
|
|
| |
If we know we are producing an object, we don't need to wrap the stream
in a formatted_raw_ostream anymore.
llvm-svn: 234461
|
| |
|
|
| |
llvm-svn: 234438
|
| |
|
|
|
|
|
| |
Fixed insert point for allocas created for demoted values.
Clear the nested landing pad list after it has been processed.
llvm-svn: 234433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|