| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
lack sse2.
llvm-svn: 112175
|
|
|
|
| |
llvm-svn: 112171
|
|
|
|
| |
llvm-svn: 112155
|
|
|
|
| |
llvm-svn: 112104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expanding: e.g. <2 x float> -> <4 x float> instead of -> 2 floats. This
affects two places in the code: handling cross block values and handling
function return and arguments. Since vectors are already widened by
legalizetypes, this gives us much better code and unblocks x86-64 abi
and SPU abi work.
For example, this (which is a silly example of a cross-block value):
define <4 x float> @test2(<4 x float> %A) nounwind {
%B = shufflevector <4 x float> %A, <4 x float> undef, <2 x i32> <i32 0, i32 1>
%C = fadd <2 x float> %B, %B
br label %BB
BB:
%D = fadd <2 x float> %C, %C
%E = shufflevector <2 x float> %D, <2 x float> undef, <4 x i32> <i32 0, i32 1, i32 undef, i32 undef>
ret <4 x float> %E
}
Now compiles into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
addps %xmm0, %xmm0
ret
previously it compiled into:
_test2: ## @test2
## BB#0:
addps %xmm0, %xmm0
pshufd $1, %xmm0, %xmm1
## kill: XMM0<def> XMM0<kill> XMM0<def>
insertps $0, %xmm0, %xmm0
insertps $16, %xmm1, %xmm0
addps %xmm0, %xmm0
ret
This implements rdar://8230384
llvm-svn: 112101
|
|
|
|
| |
llvm-svn: 112086
|
|
|
|
| |
llvm-svn: 112085
|
|
|
|
| |
llvm-svn: 112084
|
|
|
|
|
|
| |
no functionality change.
llvm-svn: 111994
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 111990
|
|
|
|
| |
llvm-svn: 111982
|
|
|
|
|
|
| |
access. rdar://8277890&7352504
llvm-svn: 111968
|
|
|
|
|
|
|
| |
For now it's still a command line option, but the interface to the generic
code doesn't need to know that.
llvm-svn: 111942
|
|
|
|
| |
llvm-svn: 111870
|
|
|
|
| |
llvm-svn: 111847
|
|
|
|
|
|
|
| |
relative offsets when there are offsets encoded in the instructions and
simplifies final allocation in PEI. rdar://8277890
llvm-svn: 111836
|
|
|
|
|
|
| |
PR 7920.
llvm-svn: 111820
|
|
|
|
|
|
| |
passes over to the new registration API.
llvm-svn: 111815
|
|
|
|
|
|
|
| |
hierarchy with virtual methods and using llvm_unreachable to properly indicate
unreachable states which would otherwise leave variables uninitialized.
llvm-svn: 111803
|
|
|
|
| |
llvm-svn: 111744
|
|
|
|
|
|
|
|
|
|
|
| |
It's similar to "linker_private_weak", but it's known that the address of the
object is not taken. For instance, functions that had an inline definition, but
the compiler decided not to inline it. Note, unlike linker_private and
linker_private_weak, linker_private_weak_def_auto may have only default
visibility. The symbols are removed by the linker from the final linked image
(executable or dynamic library).
llvm-svn: 111684
|
|
|
|
| |
llvm-svn: 111673
|
|
|
|
| |
llvm-svn: 111670
|
|
|
|
| |
llvm-svn: 111646
|
|
|
|
|
|
|
|
|
|
|
| |
it involves specific floating-point types, legalize should expand an
extending load to a non-extending load followed by a separate extend operation.
For example, we currently expand SEXTLOAD to EXTLOAD+SIGN_EXTEND_INREG (and
assert that EXTLOAD should always be supported). Now we can expand that to
LOAD+SIGN_EXTEND. This is needed to allow vector SIGN_EXTEND and ZERO_EXTEND
to be used for NEON.
llvm-svn: 111586
|
|
|
|
| |
llvm-svn: 111585
|
|
|
|
| |
llvm-svn: 111575
|
|
|
|
| |
llvm-svn: 111574
|
|
|
|
| |
llvm-svn: 111540
|
|
|
|
| |
llvm-svn: 111537
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
implements parts of C++0x based on the draft standard. An old version of
the draft had a bug that makes std::pair<T1*, T2*>(something, 0) fail to
compile. This is because the template<class U, class V> pair(U&& x, V&& y)
constructor is selected, even though it later fails to implicitly convert
U and V to frist_type and second_type.
This has been fixed in n3090, but it seems that Microsoft is not going to
update msvc.
llvm-svn: 111535
|
|
|
|
| |
llvm-svn: 111531
|
|
|
|
| |
llvm-svn: 111530
|
|
|
|
|
|
|
| |
base registers were required. This will allow for slightly better packing
of the locals when alignment padding is necessary after callee saved registers.
llvm-svn: 111508
|
|
|
|
| |
llvm-svn: 111453
|
|
|
|
|
|
| |
safe to sink it to a successor block. This bug has been hidden because a later check for critical-edge disable these illegal optimizations. This patch should significantly reduce the amount of time spent on checking dominator information for obviously unsafe sinking.
llvm-svn: 111450
|
|
|
|
|
|
|
|
|
| |
frame index reference to an object in the local block is seen, check if
it's near enough to any previously allocaated base register to re-use.
rdar://8277890
llvm-svn: 111443
|
|
|
|
|
|
| |
map discovers the iterated dominance frontier for free.
llvm-svn: 111400
|
|
|
|
|
|
|
|
|
|
| |
We must complete the DFS, otherwise we might miss needed phi-defs, and
prematurely color live ranges with a non-dominating value.
This is not a big deal since we get to color more of the CFG and the next
mapValue call will be faster.
llvm-svn: 111397
|
|
|
|
| |
llvm-svn: 111394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LiveIntervalMap maps values from a parent LiveInterval to a child interval that
is a strict subset. It will create phi-def values as needed to preserve the
VNInfo SSA form in the child interval.
This leads to an algorithm very similar to the one in SSAUpdaterImpl.h, but with
enough differences that the code can't be reused:
- We don't need to manipulate PHI instructions.
- LiveIntervals have kills.
- We have MachineDominatorTree.
- We can use df_iterator.
llvm-svn: 111393
|
|
|
|
| |
llvm-svn: 111384
|
|
|
|
|
|
|
|
|
|
| |
Nothing fancy, just ask the target if any currently available base reg
is in range for the instruction under consideration and use the first one
that is. Placeholder ARM implementation simply returns false for now.
ongoing saga of rdar://8277890
llvm-svn: 111374
|
|
|
|
| |
llvm-svn: 111366
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the local block. Resolve references to those indices to a new base register.
For simplification and testing purposes, a new virtual base register is
allocated for each frame index being resolved. The result is truly horrible,
but correct, code that's good for exercising the new code paths.
Next up is adding thumb1 support, which should be very simple. Following that
will be adding base register re-use and implementing a reasonable ARM
heuristic for when a virtual base register should be generated at all.
llvm-svn: 111315
|
|
|
|
|
|
| |
PR 7882. Follows suggestion by Amaury Pouly, thanks.
llvm-svn: 111306
|
|
|
|
|
|
| |
Move the requirement to LiveIntervalAnalysis instead. Note this does not change the number of times machineloopinfo is computed.
llvm-svn: 111285
|
|
|
|
|
|
| |
machine cse before.
llvm-svn: 111281
|
|
|
|
| |
llvm-svn: 111274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whether to allocate a virtual frame base register to resolve the frame
index reference in it. Implement a simple version for ARM to aid debugging.
In LocalStackSlotAllocation, scan the function for frame index references
to local frame indices and ask the target whether to allocate virtual
frame base registers for any it encounters. Purely infrastructural for
debug output. Next step is to actually allocate base registers, then add
intelligent re-use of them.
rdar://8277890
llvm-svn: 111262
|