| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 133347
|
|
|
|
|
|
|
|
|
| |
range without a libcall to a new mulo<mode> libcall
that we'd have to create.
Finishes the rest of rdar://9090077 and rdar://9210061
llvm-svn: 133318
|
|
|
|
| |
llvm-svn: 133313
|
|
|
|
| |
llvm-svn: 133307
|
|
|
|
| |
llvm-svn: 133292
|
|
|
|
|
|
|
|
|
| |
calls if we haven't been able to lower them any
other way.
Fixes rdar://9090077 and rdar://9210061
llvm-svn: 133288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LSDA is a bit difficult for the non-initiated to read. Even with comments,
it's not always clear what's going on. This wraps the ASM streamer in a class
that retains the LSDA and then emits a human-readable description of what's
going on in it.
So instead of having to make sense of:
Lexception1:
.byte 255
.byte 155
.byte 168
.space 1
.byte 3
.byte 26
Lset0 = Ltmp7-Leh_func_begin1
.long Lset0
Lset1 = Ltmp812-Ltmp7
.long Lset1
Lset2 = Ltmp913-Leh_func_begin1
.long Lset2
.byte 3
Lset3 = Ltmp812-Leh_func_begin1
.long Lset3
Lset4 = Leh_func_end1-Ltmp812
.long Lset4
.long 0
.byte 0
.byte 1
.byte 0
.byte 2
.byte 125
.long __ZTIi@GOTPCREL+4
.long __ZTIPKc@GOTPCREL+4
you can read this instead:
## Exception Handling Table: Lexception1
## @LPStart Encoding: omit
## @TType Encoding: indirect pcrel sdata4
## @TType Base: 40 bytes
## @CallSite Encoding: udata4
## @Action Table Size: 26 bytes
## Action 1:
## A throw between Ltmp7 and Ltmp812 jumps to Ltmp913 on an exception.
## For type(s): __ZTIi@GOTPCREL+4 __ZTIPKc@GOTPCREL+4
## Action 2:
## A throw between Ltmp812 and Leh_func_end1 does not have a landing pad.
llvm-svn: 133286
|
|
|
|
| |
llvm-svn: 133271
|
|
|
|
| |
llvm-svn: 133265
|
|
|
|
|
|
|
|
| |
* We should change the generated code because of a debug use.
* Avoid creating debug uses of undef, as they become a kill.
Test to follow.
llvm-svn: 133255
|
|
|
|
|
|
| |
PBQP allocation. Patch by Arnaud Allard de Grandmaison.
llvm-svn: 133249
|
|
|
|
|
|
| |
be made, but this is already a win.
llvm-svn: 133240
|
|
|
|
|
|
|
|
|
|
|
| |
Also switch the return type to ArrayRef<unsigned> which works out nicely
for ARM's implementation of this function because of the clever ArrayRef
constructors.
The name change indicates that the returned allocation order may contain
reserved registers as has been the case for a while.
llvm-svn: 133216
|
|
|
|
|
|
|
|
|
|
| |
In Thumb mode we cannot handle GPR virtual registers, even though some
instructions can. When isel is lowering a CopyFromReg, it should limit
itself to subclasses of getRegClassFor(VT).
<rdar://problem/9624323>
llvm-svn: 133210
|
|
|
|
|
|
| |
No functional change was intended.
llvm-svn: 133202
|
|
|
|
|
|
|
| |
I think PBQP could use RegisterClassInfo, but it didn't fit neatly with
the external interfaces that PBQP uses, so I'll leave that to Lang.
llvm-svn: 133186
|
|
|
|
|
|
|
|
| |
BranchProbabilityInfo (expect setEdgeWeight which is not available here).
Branch Weights are kept in MachineBasicBlocks. To turn off this analysis
set -use-mbpi=false.
llvm-svn: 133184
|
|
|
|
|
|
|
|
| |
first operand. This operand is lowered away by the time we reach MachineInstrs, so the actual register-allocation handling of them doesn't need to change.
This is intended to support using REG_SEQUENCE SDNode's with type MVT::untyped, and is part of the long road to eliminating some of the hacks we currently use to support register pairs and other strange constraints, particularly on ARM NEON.
llvm-svn: 133178
|
|
|
|
|
|
|
|
|
| |
This avoids the manual filtering of reserved registers and removes the
dependency on allocation_order_begin().
Palliative care...
llvm-svn: 133177
|
|
|
|
| |
llvm-svn: 133174
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This virtual function will replace allocation_order_begin/end as the one
to override when implementing custom allocation orders. It is simpler to
have one function return an ArrayRef than having two virtual functions
computing different ends of the same array.
Use getRawAllocationOrder() in place of allocation_order_begin() where
it makes sense, but leave some clients that look like they really want
the filtered allocation orders from RegisterClassInfo.
llvm-svn: 133170
|
|
|
|
| |
llvm-svn: 133124
|
|
|
|
|
|
| |
the upper limit on the block IDs since basic blocks might get removed (simplified away) after being initially numbered. Plus the test case, in which SelectionDAGBuilder::visitBr() calls llvm::MachineFunction::removeFromMBBNumbering(), which introduces the hole in numbering leading to an assert in llc (prior to the fix).
llvm-svn: 133113
|
|
|
|
| |
llvm-svn: 133108
|
|
|
|
|
|
| |
features like register pairs and lists with "interesting" constraints (such as ARM NEON contiguous register lists or even-odd paired registers). We need to be able to generate these instructions (often from intrinsics), but don't want to have to assign a legal type to them. Instead, we'll use an "untyped" edge to bypass the type-checking and simply ensure that the register classes match.
llvm-svn: 133106
|
|
|
|
| |
llvm-svn: 133083
|
|
|
|
|
|
| |
Added a test case for handling physreg aliases during pre-RA-sched.
llvm-svn: 133063
|
|
|
|
| |
llvm-svn: 133057
|
|
|
|
|
|
|
|
| |
GetDemandBits (which must operate on the vector element type).
Fix the a usage of getZeroExtendInReg which must also be done on scalar types.
llvm-svn: 133052
|
|
|
|
|
|
|
|
| |
converted to add x,x if x is a undef. add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.
llvm-svn: 133022
|
|
|
|
| |
llvm-svn: 133007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dan noted that this would work on the case shown on the commit message. I think
the case that was failing was a bb ending with a redundant conditional jump:
...
jne foo
foo:
...
I was unable to find any such case in the tests or in a debug build of clang,
so I will revert this part of the patch and watch the bots.
llvm-svn: 133004
|
|
|
|
| |
llvm-svn: 132995
|
|
|
|
| |
llvm-svn: 132988
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types (with power of two types such as 8,16,32 .. 512).
Fix a bug in the integer promotion of bitcast nodes. Enable integer expanding
only if the target of the conversion is an integer (when the type action is
scalarize).
Add handling to the legalization of vector load/store in cases where the saved
vector is integer-promoted.
llvm-svn: 132985
|
|
|
|
| |
llvm-svn: 132984
|
|
|
|
|
|
| |
AnalyzeBranch.
llvm-svn: 132981
|
|
|
|
|
|
|
| |
or instruction cache access. Update the targets to match it and also teach
autoupgrade.
llvm-svn: 132976
|
|
|
|
|
|
|
| |
sharp all or nothing transition when one extra predecessor was added. Now
we still test first ones for merging.
llvm-svn: 132974
|
|
|
|
|
|
|
| |
only if the number of packed elements is a power of two.
Bug found in Duncan's testcase.
llvm-svn: 132923
|
|
|
|
|
|
|
|
|
|
| |
In particular, don't spill dirty registers only to satisfy a hint. It is
not worth it.
The attached test case provides an example where the fast allocator
would spill a register when other registers are available.
llvm-svn: 132900
|
|
|
|
| |
llvm-svn: 132899
|
|
|
|
|
|
| |
having.
llvm-svn: 132898
|
|
|
|
|
|
| |
types such as i33 were rounded to i32. Originated from Duncan's testcase.
llvm-svn: 132893
|
|
|
|
|
|
|
|
|
| |
Instead of scalarizing, and doing an element-by-element truncat, use vector
truncate.
Add support for scalarization of vectors: i8 -> <1 x i1> (from Duncan's
testcase).
llvm-svn: 132892
|
|
|
|
|
|
| |
Add a triple to the tests.
llvm-svn: 132885
|
|
|
|
| |
llvm-svn: 132883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we try to branch to them.
Before we were creating successor lists with duplicated entries. Fixing that
found a bug in isBlockOnlyReachableByFallthrough that would causes it to
return the wrong answer for
-----------
...
jne foo
jmp bar
foo:
----------
llvm-svn: 132882
|
|
|
|
| |
llvm-svn: 132872
|
|
|
|
| |
llvm-svn: 132871
|