- May 17, 2010
-
-
Evan Cheng authored
Using NEON load / store multiple instructions will no longer create gobs of vmov of D registers! llvm-svn: 103960
-
Evan Cheng authored
llvm-svn: 103917
-
- May 16, 2010
-
-
Anton Korobeynikov authored
llvm-svn: 103903
-
Anton Korobeynikov authored
llvm-svn: 103901
-
Evan Cheng authored
llvm-svn: 103898
-
- May 15, 2010
-
-
Anton Korobeynikov authored
This can be extended later on to handle more "complex" constants. llvm-svn: 103881
-
Anton Korobeynikov authored
Temporary emit it as raw bytes until it will be added to binutils as well. llvm-svn: 103878
-
Evan Cheng authored
llvm-svn: 103868
-
Evan Cheng authored
llvm-svn: 103855
-
Evan Cheng authored
allow target to override it in order to map register classes to illegal but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON. llvm-svn: 103854
-
Evan Cheng authored
llvm-svn: 103851
-
Evan Cheng authored
instructions. e.g. %reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0 %reg1027<def> = EXTRACT_SUBREG %reg1026, 6 %reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5 ... %reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12 After REG_SEQUENCE is eliminated, we are left with: %reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0 %reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6 %reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5 The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger sub-register (or combined to be reg1026 itself as is the case here). If it is possible, it will be able to replace references of reg1026 with reg1029 + the larger sub-register index. llvm-svn: 103835
-
Evan Cheng authored
llvm-svn: 103833
-
- May 14, 2010
-
-
Bill Wendling authored
the variable actually tracks. N.B., several back-ends are using "HasCalls" as being synonymous for something that adjusts the stack. This isn't 100% correct and should be looked into. llvm-svn: 103802
-
Evan Cheng authored
llvm-svn: 103790
-
Evan Cheng authored
llvm-svn: 103760
-
Evan Cheng authored
llvm-svn: 103749
-
- May 13, 2010
-
-
Evan Cheng authored
llvm-svn: 103731
-
Bob Wilson authored
Do not use those for Thumb1 functions. llvm-svn: 103730
-
Daniel Dunbar authored
llvm-svn: 103694
-
Evan Cheng authored
Bring back VLD1q and VST1q and use them for reloading / spilling Q registers. This allows folding loads and stores into VMOVQ. llvm-svn: 103692
-
Evan Cheng authored
llvm-svn: 103684
-
Evan Cheng authored
llvm-svn: 103683
-
Evan Cheng authored
Fix some potential issues in the pseudo instruction expansion phase: copy implicit operands and memoperands. Also, expand instructions even if their defs are "dead" since they may have implicit kill operands. llvm-svn: 103667
-
- May 12, 2010
-
-
Evan Cheng authored
llvm-svn: 103642
-
Rafael Espindola authored
llvm-svn: 103576
-
Evan Cheng authored
v1024 = REG_SEQUENCE ... v1025 = EXTRACT_SUBREG v1024, 5 v1026 = EXTRACR_SUBREG v1024, 6 = VSTxx <addr>, v1025, v1026 The REG_SEQUENCE ensures the sources that feed into the VST instruction are getting the right register allocation so they form a large super- register. The extract_subreg will be coalesced away all would just work: v1024 = REG_SEQUENCE ... = VSTxx <addr>, v1024:5, v1024:6 The problem is if the coalescer isn't run, the extract_subreg instructions would stick around and there is no assurance v1025 and v1026 will get the right registers. As a short term workaround, teach the NEON pre-allocation pass to transfer the sub-register indices over. An alternative would be do it 2addr pass when reg_sequence's are eliminated. But that *seems* wrong and require updating liveness information. Another alternative is to do this in the scheduler when the instructions are created. But that would mean somehow the scheduler this has to be done for correctness reason. That's yucky as well. So for now, we are leaving this in the target specific pass. llvm-svn: 103540
-
- May 11, 2010
-
-
Evan Cheng authored
llvm-svn: 103513
-
Duncan Sands authored
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is the opposite, for future use by dragonegg. llvm-svn: 103495
-
Dan Gohman authored
Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and EmitTargetCodeForMemmove out of TargetLowering and into SelectionDAGInfo to exercise this. llvm-svn: 103481
-
Dan Gohman authored
was unused. TargetMachine::getSubtarget() is used instead. llvm-svn: 103474
-
Evan Cheng authored
llvm-svn: 103459
-
Evan Cheng authored
llvm-svn: 103453
-
- May 10, 2010
-
-
Evan Cheng authored
llvm-svn: 103437
-
Evan Cheng authored
llvm-svn: 103411
-
- May 07, 2010
-
-
Jim Grosbach authored
whether the extract instructions are available. rdar://7956878 llvm-svn: 103277
-
Evan Cheng authored
Use VLD2q32 / VST2q32 to reload / spill QQ (pair of Q) registers when stack slot is sufficiently aligned. Use VLDMD / VSTMD otherwise. llvm-svn: 103235
-
Evan Cheng authored
Use VSTMD / VLDMD for spills and reloads of Q registers instead of VSTMQ / VLDQ. The later are aliases which ought to be eliminated but we can't because they are used for storing and loading v2f64 values. llvm-svn: 103234
-
Evan Cheng authored
Remove VLD1q and VST1q for reloading and spilling Q registers. Just use VLD1q64 / VST1q64 and reference sub-registers. llvm-svn: 103218
-
- May 06, 2010
-
-
Dan Gohman authored
doesn't have to guess. llvm-svn: 103194
-