| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 169624
|
| |
|
|
|
|
|
|
|
|
| |
understand target implementation of any_extend / extload, just generate
zero_extend in place of any_extend for liveouts when the target knows the
zero_extend will be implicit (e.g. ARM ldrb / ldrh) or folded (e.g. x86 movz).
rdar://12771555
llvm-svn: 169536
|
| |
|
|
| |
llvm-svn: 169534
|
| |
|
|
| |
llvm-svn: 169521
|
| |
|
|
|
|
| |
to the normal instructions.
llvm-svn: 169482
|
| |
|
|
|
|
| |
neverHasSideEffects.
llvm-svn: 169477
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and extload's. If they are implemented as zero-extend, or implicitly
zero-extend, then this can enable more demanded bits optimizations. e.g.
define void @foo(i16* %ptr, i32 %a) nounwind {
entry:
%tmp1 = icmp ult i32 %a, 100
br i1 %tmp1, label %bb1, label %bb2
bb1:
%tmp2 = load i16* %ptr, align 2
br label %bb2
bb2:
%tmp3 = phi i16 [ 0, %entry ], [ %tmp2, %bb1 ]
%cmp = icmp ult i16 %tmp3, 24
br i1 %cmp, label %bb3, label %exit
bb3:
call void @bar() nounwind
br label %exit
exit:
ret void
}
This compiles to the followings before:
push {lr}
mov r2, #0
cmp r1, #99
bhi LBB0_2
@ BB#1: @ %bb1
ldrh r2, [r0]
LBB0_2: @ %bb2
uxth r0, r2
cmp r0, #23
bhi LBB0_4
@ BB#3: @ %bb3
bl _bar
LBB0_4: @ %exit
pop {lr}
bx lr
The uxth is not needed since ldrh implicitly zero-extend the high bits. With
this change it's eliminated.
rdar://12771555
llvm-svn: 169459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for the lldb team so most of but not all of the values are
to be printed as hex with this option. Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.
There may be some tweaks need to places that may still be in
decimal that they want in hex. Specially for arm. I made my best
guess. Any tweaks from here should be simple.
I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes. But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.
rdar://8109283
llvm-svn: 169393
|
| |
|
|
|
|
| |
Generate VPBLENDD for AVX2 and VPBLENDW for v16i16 type on AVX2.
llvm-svn: 169366
|
| |
|
|
|
|
|
|
|
| |
x ^ -1.
Patch by David Majnemer.
rdar://12755626
llvm-svn: 169339
|
| |
|
|
|
|
|
|
|
| |
textually as NativeClient. Also added a link to the native client project for
readers unfamiliar with it.
A Clang patch will follow shortly.
llvm-svn: 169291
|
| |
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This revision attempts to recognize following population-count pattern:
while(a) { c++; ... ; a &= a - 1; ... },
where <c> and <a>could be used multiple times in the loop body.
TODO: On X8664 and ARM, __buildin_ctpop() are not expanded to a efficent
instruction sequence, which need to be improved in the following commits.
Reviewed by Nadav, really appreciate!
llvm-svn: 168931
|
| |
|
|
|
|
|
|
| |
X86IselLowering.cpp.
The logic was not changed, only names.
llvm-svn: 168875
|
| |
|
|
|
|
| |
This class has been merged into its super-class TargetInstrInfo.
llvm-svn: 168760
|
| |
|
|
|
|
|
|
|
|
|
| |
when the destination register is wider than the memory load.
These load instructions load from m32 or m64 and set the upper bits to zero,
while the folded instructions may accept m128.
rdar://12721174
llvm-svn: 168710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass was conservative in that it always reserved the FP to enable dynamic
stack realignment, which allowed the RA to use aligned spills for vector
registers. This happens even when spills were not necessary. The RA has
since been improved to use unaligned spills when necessary.
The new behavior is to realign the stack if the frame pointer was already
reserved for some other reason, but don't reserve the frame pointer just
because a function contains vector virtual registers.
Part of rdar://12719844
llvm-svn: 168627
|
| |
|
|
| |
llvm-svn: 168600
|
| |
|
|
| |
llvm-svn: 168597
|
| |
|
|
|
|
|
|
| |
MachineInstrBuilder.
Simplify some repetitive code with it. No functionality change.
llvm-svn: 168587
|
| |
|
|
| |
llvm-svn: 168417
|
| |
|
|
|
|
| |
that llvm.muladd can be converted to ISD::FMA for fp_contract.
llvm-svn: 168413
|
| |
|
|
| |
llvm-svn: 168409
|
| |
|
|
| |
llvm-svn: 168407
|
| |
|
|
| |
llvm-svn: 168396
|
| |
|
|
| |
llvm-svn: 168359
|
| |
|
|
| |
llvm-svn: 168166
|
| |
|
|
|
|
| |
vector types.
llvm-svn: 168141
|
| |
|
|
| |
llvm-svn: 168076
|
| |
|
|
| |
llvm-svn: 168064
|
| |
|
|
| |
llvm-svn: 168025
|
| |
|
|
| |
llvm-svn: 168006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bytes.
The stack realignment code was fixed to work when there is stack realignment and
a dynamic alloca is present so this shouldn't cause correctness issues anymore.
Note that this also enables generation of AVX instructions for memset
under the assumptions:
- Unaligned loads/stores are always fast on CPUs supporting AVX
- AVX is not slower than SSE
We may need some tweaked heuristics if one of those assumptions turns out not to
be true.
Effectively reverts r58317. Part of PR2962.
llvm-svn: 167967
|
| |
|
|
|
|
|
|
|
|
| |
When an instruction as written requires 32-bit mode and we're assembling
in 64-bit mode, or vice-versa, issue a more specific diagnostic about
what's wrong.
rdar://12700702
llvm-svn: 167937
|
| |
|
|
| |
llvm-svn: 167916
|
| |
|
|
|
|
|
|
| |
Do some cleanup of the code while here.
Inspired by patch by Logan Chien!
llvm-svn: 167904
|
| |
|
|
|
|
|
|
|
|
|
| |
chain is correctly setup.
As an example, if the original load must happen before later stores, we need
to make sure the constructed VZEXT_LOAD is constrained to be before the stores.
rdar://12684358
llvm-svn: 167859
|
| |
|
|
|
|
|
| |
- Fix operand order for atomic sub, where the minuend is the value
loaded from memory and the subtrahend is the parameter specified.
llvm-svn: 167718
|
| |
|
|
| |
llvm-svn: 167696
|
| |
|
|
| |
llvm-svn: 167673
|
| |
|
|
| |
llvm-svn: 167671
|
| |
|
|
| |
llvm-svn: 167670
|
| |
|
|
|
|
| |
functions static.
llvm-svn: 167669
|
| |
|
|
| |
llvm-svn: 167652
|
| |
|
|
|
|
| |
reverts r126226.
llvm-svn: 167632
|
| |
|
|
| |
llvm-svn: 167607
|
| |
|
|
|
|
|
|
| |
- Add RTM code generation support throught 3 X86 intrinsics:
xbegin()/xend() to start/end a transaction region, and xabort() to abort a
tranaction region
llvm-svn: 167573
|
| |
|
|
| |
llvm-svn: 167505
|
| |
|
|
| |
llvm-svn: 167501
|