| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 153513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Late optimization passes like branch folding and tail duplication can
transform the machine code in a way that makes it expensive to keep the
register liveness information up to date. There is a fuzzy line between
register allocation and late scheduling where the liveness information
degrades.
The MRI::tracksLiveness() flag makes the line clear: While true,
liveness information is accurate, and can be used for register
scavenging. Once the flag is false, liveness information is not
accurate, and can only be used as a hint.
Late passes generally don't need the liveness information, but they will
sometimes use the register scavenger to help update it. The scavenger
enforces strict correctness, and we have to spend a lot of code to
update register liveness that may never be used.
llvm-svn: 153511
|
| |
|
|
|
|
|
|
| |
register that's read by the preheader terminator.
rdar://11095580
llvm-svn: 153492
|
| |
|
|
|
|
|
|
|
|
| |
copies being considered for removal. Make sure to track all of the copies,
rather than just the most recent encountered, by holding a DenseSet instead of
an unsigned in SrcMap.
No test case - couldn't reduce something with a sane size.
llvm-svn: 153487
|
| |
|
|
| |
llvm-svn: 153483
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
backtrace locations.
Testcase forthcoming, but I wanted to get some testing here.
Should fix:
PR12323
PR12314
rdar://11091100
llvm-svn: 153471
|
| |
|
|
| |
llvm-svn: 153438
|
| |
|
|
| |
llvm-svn: 153429
|
| |
|
|
| |
llvm-svn: 153428
|
| |
|
|
|
|
| |
PPC64 SVR4 ABI.
llvm-svn: 153372
|
| |
|
|
|
|
|
| |
Dump the hex representation to the comment stream as well as the float
value.
llvm-svn: 153346
|
| |
|
|
| |
llvm-svn: 153341
|
| |
|
|
|
|
| |
rdar://11096639
llvm-svn: 153270
|
| |
|
|
|
|
| |
rdar://11096639
llvm-svn: 153269
|
| |
|
|
|
|
|
|
|
| |
metadata operand as an actual operand, leading to an assert. Error
out in this case.
rdar://11007633
llvm-svn: 153234
|
| |
|
|
|
|
|
|
|
| |
execution-time regression for nsieve-bits on the ARMv7 -O0 -g nightly tester.
This may also improve compile-time on architectures that would otherwise
generate a libcall for urem (e.g., ARM) or fall back to the DAG selector.
rdar://10810716
llvm-svn: 153230
|
| |
|
|
|
|
|
|
| |
Type legalization can zero-extend the elements of the build_vector node, so,
for example, we may have an <8 x i8> with i32 elements of value 255. That
should return 'true' for the vector being all ones.
llvm-svn: 153203
|
| |
|
|
| |
llvm-svn: 153162
|
| |
|
|
| |
llvm-svn: 153161
|
| |
|
|
| |
llvm-svn: 153160
|
| |
|
|
| |
llvm-svn: 153159
|
| |
|
|
| |
llvm-svn: 153158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:
0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)
The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>
llvm-svn: 153081
|
| |
|
|
|
|
| |
users of the final load to the worklist too. Needed by changes I'm preparing to make to X86 backend.
llvm-svn: 153078
|
| |
|
|
|
|
|
|
|
|
| |
a variable. The previous code would break the debug info changing
code invariant. This will regress debug info for arguments where
we elide the alloca created.
Fixes rdar://11066468
llvm-svn: 153074
|
| |
|
|
| |
llvm-svn: 153073
|
| |
|
|
| |
llvm-svn: 153072
|
| |
|
|
| |
llvm-svn: 153071
|
| |
|
|
| |
llvm-svn: 153064
|
| |
|
|
|
|
|
| |
instructions have been scheduled. Handy for tracking down scheduler bugs, or
bugs exposed by scheduling.
llvm-svn: 153045
|
| |
|
|
| |
llvm-svn: 153035
|
| |
|
|
| |
llvm-svn: 152999
|
| |
|
|
|
|
| |
This is particularly helpful as both arguments tend to be constants.
llvm-svn: 152991
|
| |
|
|
|
|
| |
the beginning, no need to maintain another set for the added regs.
llvm-svn: 152934
|
| |
|
|
|
|
|
|
| |
number in padding.
Saves one machine word on MachineInstr (88->80 bytes on x86_64, 48->44 on i386).
llvm-svn: 152930
|
| |
|
|
|
|
|
|
| |
the cached value.
No functionality change.
llvm-svn: 152927
|
| |
|
|
|
|
|
|
|
|
| |
These edges are not really necessary, but it is consistent with the
way we currently create physreg edges. Scheduler heuristics that
expect a DAG edge to the block terminator could benefit from this
change. Although in the future I hope we have a better mechanism for
modeling latency across scheduling regions.
llvm-svn: 152895
|
| |
|
|
|
|
|
|
|
|
|
| |
on our internal nightly testers. So, basically revert r152486 again.
Abbreviated original commit message:
Implement a more intelligent way of spilling uses across an invoke boundary.
It looks as if Chander's inlining work, r152737, exposed an issue.
llvm-svn: 152887
|
| |
|
|
|
|
|
|
|
| |
for workaround of g++-4.4's miscompilation.
It caused MSP430DAGToDAGISel::SelectIndexedBinOp() to be miscompiled.
When two ReplaceUses()'s are expanded as inline, vtable in base class is stored to latter (ISelUpdater)ISU.
llvm-svn: 152877
|
| |
|
|
|
|
|
|
| |
the DECL information.
rdar://10855921
llvm-svn: 152876
|
| |
|
|
|
|
| |
Part of rdar://8905263
llvm-svn: 152845
|
| |
|
|
| |
llvm-svn: 152844
|
| |
|
|
| |
llvm-svn: 152843
|
| |
|
|
| |
llvm-svn: 152842
|
| |
|
|
| |
llvm-svn: 152841
|
| |
|
|
|
|
| |
add the new node into the work list because there is a potential for further optimizations.
llvm-svn: 152784
|
| |
|
|
|
|
|
|
|
| |
out the DW_AT_name. Older gdbs unfortunately still use it to
disambiguate member functions in templated classes (gdb.cp/templates.exp).
rdar://11043421 (which is now deferred for a bit)
llvm-svn: 152782
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Transform:
(fsub x, (fadd x, y)) -> (fneg y) and
(fsub x, (fadd y, x)) -> (fneg y)
if 'unsafe math' is specified.
<rdar://problem/7540295>
llvm-svn: 152777
|
| |
|
|
| |
llvm-svn: 152711
|
| |
|
|
|
|
|
|
|
| |
There were cases where a value could be used and it's both crossing an invoke
and NOT crossing an invoke. This could happen in the landing pads. In that case,
we will demote the value to the stack like we did before.
<rdar://problem/10609139>
llvm-svn: 152705
|