| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous change to local live range allocation also suppressed
eviction of local ranges. In rare cases, this could result in more
expensive register choices. This commit actually revives a feature
that I added long ago: check if live ranges can be reassigned before
eviction. But now it only happens in rare cases of evicting a local
live range because another local live range wants a cheaper register.
The benefit is improved code size for some benchmarks on x86 and armv7.
I measured no significant compile time increase and performance
changes are noise.
llvm-svn: 187140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also avoid locals evicting locals just because they want a cheaper register.
Problem: MI Sched knows exactly how many registers we have and assumes
they can be colored. In cases where we have large blocks, usually from
unrolled loops, greedy coloring fails. This is a source of
"regressions" from the MI Scheduler on x86. I noticed this issue on
x86 where we have long chains of two-address defs in the same live
range. It's easy to see this in matrix multiplication benchmarks like
IRSmk and even the unit test misched-matmul.ll.
A fundamental difference between the LLVM register allocator and
conventional graph coloring is that in our model a live range can't
discover its neighbors, it can only verify its neighbors. That's why
we initially went for greedy coloring and added eviction to deal with
the hard cases. However, for singly defined and two-address live
ranges, we can optimally color without visiting neighbors simply by
processing the live ranges in instruction order.
Other beneficial side effects:
It is much easier to understand and debug regalloc for large blocks
when the live ranges are allocated in order. Yes, global allocation is
still very confusing, but it's nice to be able to comprehend what
happened locally.
Heuristics could be added to bias register assignment based on
instruction locality (think late register pairing, banks...).
Intuituvely this will make some test cases that are on the threshold
of register pressure more stable.
llvm-svn: 187139
|
| |
|
|
| |
llvm-svn: 187138
|
| |
|
|
| |
llvm-svn: 187135
|
| |
|
|
|
|
|
| |
The last patch corrected some issues, but constant-pool entries had actual
codegen bugs in the large memory model (which MCJIT uses).
llvm-svn: 187126
|
| |
|
|
| |
llvm-svn: 187124
|
| |
|
|
|
|
|
| |
This should actually make the MCJIT tests pass again on AArch64. I don't know
how I missed their failure before.
llvm-svn: 187120
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch we took advantage of the fact that the compare and
branch are glued together in the selection DAG and fused them together
(where possible) while emitting them. This seemed to work well in practice.
However, fusing the compare so early makes it harder to remove redundant
compares in cases where CC already has a suitable value. This patch
therefore uses the peephole analyzeCompare/optimizeCompareInstr pair of
functions instead.
No behavioral change intended, but it paves the way for a later patch.
llvm-svn: 187116
|
| |
|
|
| |
llvm-svn: 187113
|
| |
|
|
|
|
|
| |
As with the stores, these instructions can trap when the condition is false,
so they are only used for things like (cond ? x : *ptr).
llvm-svn: 187112
|
| |
|
|
|
|
|
|
| |
These instructions are allowed to trap even if the condition is false,
so for now they are only used for "*ptr = (cond ? x : *ptr)"-style
constructs.
llvm-svn: 187111
|
| |
|
|
|
|
| |
Consider which set is being increased or decreased before comparing.
llvm-svn: 187110
|
| |
|
|
|
|
| |
the units.
llvm-svn: 187109
|
| |
|
|
| |
llvm-svn: 187107
|
| |
|
|
|
|
|
|
| |
Make sure the context and type fields are MDNodes. We will generate
verification errors if those fields are non-empty strings.
Fix testing cases to make them pass the verifier.
llvm-svn: 187106
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The language reference says that:
"If a symbol appears in the @llvm.used list, then the compiler,
assembler, and linker are required to treat the symbol as if there is
a reference to the symbol that it cannot see"
Since even the linker cannot see the reference, we must assume that
the reference can be using the symbol table. For example, a user can add
__attribute__((used)) to a debug helper function like dump and use it from
a debugger.
llvm-svn: 187103
|
| |
|
|
| |
llvm-svn: 187099
|
| |
|
|
|
|
| |
Thanks to Nick Lewycky for noticing it.
llvm-svn: 187098
|
| |
|
|
|
|
|
|
| |
There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.
llvm-svn: 187093
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, IfConverter may widen the cases where a sequence of
instructions were executed because of the way it uses nested predicates. This
result in incorrect execution.
For instance, Let A be a basic block that flows conditionally into B and B be a
predicated block.
B can be predicated with A.BrToBPredicate into A iff B.Predicate is less
"permissive" than A.BrToBPredicate, i.e., iff A.BrToBPredicate subsumes
B.Predicate.
The IfConverter was checking the opposite: B.Predicate subsumes
A.BrToBPredicate.
<rdar://problem/14379453>
llvm-svn: 187071
|
| |
|
|
|
|
|
| |
when there wasn't a match. This behavior is consistent with other register
parsing methods.
llvm-svn: 187063
|
| |
|
|
|
|
|
| |
Improve the Finder to handle context of a DIVariable used by DbgValueInst.
Fix testing cases to make them pass the verifier.
llvm-svn: 187052
|
| |
|
|
|
|
| |
While there shrink a dangerously large SmallPtrSet.
llvm-svn: 187050
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we would strdup each argument. If one was a response file,
we would replace it with the response file contents, leaking the original
strdup result.
We now don't strdup the originals and let StringSaver free any memory it
allocated. This also saves a bit of malloc traffic when response files are
not used.
Leak found by the valgrind build bot.
llvm-svn: 187042
|
| |
|
|
|
|
|
|
|
|
| |
The Binary constructor takes ownership of the memory buffer. This is a fairly
unfortunate interface, but for now make createObjectFile consistent with it
by also deleting the buffer if it fails.
Fixes a leak in llvm-ar found by the valgrind bots.
llvm-svn: 187039
|
| |
|
|
|
|
| |
Testing commit access credentials.
llvm-svn: 187032
|
| |
|
|
|
|
|
|
| |
schedule an alloca for another iteration in SROA. This only showed up
with a mixture of promotable and unpromotable selects and phis. Added
a test case for this.
llvm-svn: 187031
|
| |
|
|
|
|
|
|
| |
includes support for the extended register set XMM16-31, YMM16-31, ZMM0-31.
The full ISA you can see here: http://software.intel.com/en-us/intel-isa-extensions
llvm-svn: 187030
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pending speculation for a phi node. The problem here is that we were
using growth of the specluation set as an indicator of whether
speculation would occur, and if the phi node is already in the set we
don't see it grow. This is a symptom of the fact that this signal is
a total hack.
Unfortunately, I couldn't really come up with a non-hacky way of
signaling that promotion remains valid *after* speculation occurs, such
that we only speculate when all else looks good for promotion. In the
end, I went with at least a much more explicit approach of doing the
work of queuing inside the phi and select processing and setting
a preposterously named flag to convey that we're in the special state of
requiring speculating before promotion.
Thanks to Richard Trieu and Nick Lewycky for the excellent work reducing
a testcase for this from a pretty giant, nasty assert in a big
application. =] The testcase was excellent.
llvm-svn: 187029
|
| |
|
|
| |
llvm-svn: 187027
|
| |
|
|
|
|
|
|
| |
asm variant.
This removes the need to store the asm variant in each row of the single table that existed before. Shaves ~16K off the size of X86AsmParser.o.
llvm-svn: 187026
|
| |
|
|
| |
llvm-svn: 187021
|
| |
|
|
|
|
| |
them from being used by the asm printer.
llvm-svn: 187020
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to ARM change r182800, dynamic linker will read bits/addends from
the original object rather than from the object that might have been patched
previously. For the purpose of relocations for MCJIT stubs on MIPS, we
internally use otherwise unused MIPS relocations.
The change also enables MCJIT unit tests for MIPS (EL/BE), and the following
two tests now pass:
- MCJITTest.return_global and
- MCJITTest.multiple_functions.
These issues have been tracked as Bug 16250.
Patch by Petar Jovanovic.
llvm-svn: 187019
|
| |
|
|
|
|
| |
to assume we're replacing. Clarify comments.
llvm-svn: 187018
|
| |
|
|
| |
llvm-svn: 187017
|
| |
|
|
|
|
|
| |
all enumerated cases. Reformat the rest of the existing constructors to
match.
llvm-svn: 187015
|
| |
|
|
|
|
|
| |
Move to a single constructor with a default argument and avoid
the check and nullification.
llvm-svn: 187014
|
| |
|
|
| |
llvm-svn: 187013
|
| |
|
|
| |
llvm-svn: 187012
|
| |
|
|
|
|
|
| |
This commit also implements these functions for R600 and removes a test
case that was relying on the buggy behavior.
llvm-svn: 187007
|
| |
|
|
|
|
|
|
|
|
| |
These are really the same address space in hardware. The only
difference is that CONSTANT_ADDRESS uses a special cache for faster
access. When we are unable to use the constant kcache for some reason
(e.g. smaller types or lack of indirect addressing) then the instruction
selector must use GLOBAL_ADDRESS loads instead.
llvm-svn: 187006
|
| |
|
|
|
|
|
| |
Improve the Finder to handle context of a DIVariable.
If Scope is a DICompileUnit, add it to the list of CUs.
llvm-svn: 187003
|
| |
|
|
| |
llvm-svn: 187002
|
| |
|
|
| |
llvm-svn: 187001
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When vectors are built from a single value, the ARM lowering issues a
scalar_to_vector node.
This node is then always morphed into a move from the general purpose unit to
the vector unit.
When the value comes from a load, this can be simplified into a vector load to
the right lane.
This patch changes the lowering of insert_vector_elt to expose a vector
friendly pattern in this situation.
This is a step toward fixing <rdar://problem/14170854>.
llvm-svn: 186999
|
| |
|
|
| |
llvm-svn: 186997
|
| |
|
|
| |
llvm-svn: 186994
|
| |
|
|
|
|
|
| |
Use getNodeField to access a field as a MDNode.
No functionality change.
llvm-svn: 186985
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.
There are other cleanups that should be done in this area:
* A client should not have to pass the size (even an explicit -1) to say if
it wants a null terminator or not, so we should probably swap the argument
order.
* The default should be to not require a null terminator. Very few clients
require this, but many end up asking for it just because it is the default.
llvm-svn: 186984
|