| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
argument, like "int $4", to not get an Assertion error.
llvm-svn: 103791
|
| |
|
|
| |
llvm-svn: 103790
|
| |
|
|
| |
llvm-svn: 103778
|
| |
|
|
|
|
| |
control barriers, not memory ordering barriers.
llvm-svn: 103777
|
| |
|
|
| |
llvm-svn: 103776
|
| |
|
|
| |
llvm-svn: 103760
|
| |
|
|
| |
llvm-svn: 103749
|
| |
|
|
|
|
| |
registers.
llvm-svn: 103731
|
| |
|
|
|
|
| |
Do not use those for Thumb1 functions.
llvm-svn: 103730
|
| |
|
|
|
|
| |
Patch by Dimitry Andric!
llvm-svn: 103727
|
| |
|
|
| |
llvm-svn: 103702
|
| |
|
|
| |
llvm-svn: 103694
|
| |
|
|
|
|
| |
registers. This allows folding loads and stores into VMOVQ.
llvm-svn: 103692
|
| |
|
|
| |
llvm-svn: 103684
|
| |
|
|
| |
llvm-svn: 103683
|
| |
|
|
|
|
| |
after testing before committing.
llvm-svn: 103681
|
| |
|
|
| |
llvm-svn: 103677
|
| |
|
|
|
|
|
|
| |
lower them to the correct x86-64 instructions since we
don't have a clean way to handle this in td files yet.
rdar://7947184
llvm-svn: 103668
|
| |
|
|
|
|
| |
implicit operands and memoperands. Also, expand instructions even if their defs are "dead" since they may have implicit kill operands.
llvm-svn: 103667
|
| |
|
|
|
|
| |
part first. rdar://7947184
llvm-svn: 103660
|
| |
|
|
| |
llvm-svn: 103642
|
| |
|
|
| |
llvm-svn: 103576
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 103535
|
| |
|
|
|
|
|
|
| |
be diced into atoms, and adjust getAtom() to take this into account.
- This fixes relocations to symbols in fixed size literal sections, for
example.
llvm-svn: 103532
|
| |
|
|
| |
llvm-svn: 103529
|
| |
|
|
| |
llvm-svn: 103513
|
| |
|
|
| |
llvm-svn: 103507
|
| |
|
|
|
|
|
| |
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
llvm-svn: 103495
|
| |
|
|
|
|
|
|
| |
and the others use the regular addPassesToEmitFile hook now, and
llc no longer needs a bunch of redundant code to handle the
whole-file case.
llvm-svn: 103492
|
| |
|
|
|
|
|
|
| |
Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.
llvm-svn: 103481
|
| |
|
|
|
|
| |
was unused. TargetMachine::getSubtarget() is used instead.
llvm-svn: 103474
|
| |
|
|
| |
llvm-svn: 103466
|
| |
|
|
| |
llvm-svn: 103459
|
| |
|
|
| |
llvm-svn: 103455
|
| |
|
|
| |
llvm-svn: 103453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string of features for that target. However LTO was using that string to pass
into the "create target machine" stuff. That stuff needed the feature string to
be in a particular form. In particular, it needed the CPU specified first and
then the attributes. If there isn't a CPU specified, it required it to be blank
-- e.g., ",+altivec". Yuck.
Modify the getDefaultSubtargetFeatures method to be a non-static member
function. For all attributes for a specific subtarget, it will add them in like
normal. It will also take a CPU string so that it can satisfy this horrible
syntax.
llvm-svn: 103451
|
| |
|
|
| |
llvm-svn: 103437
|
| |
|
|
| |
llvm-svn: 103411
|
| |
|
|
| |
llvm-svn: 103399
|
| |
|
|
|
|
| |
changed dllexport code to use EmitBytes instead of EmitRawText, and changed the export option to use /EXPORT: instead of -export: on the windows platform
llvm-svn: 103377
|
| |
|
|
| |
llvm-svn: 103373
|
| |
|
|
|
|
| |
patch by Nathan Jeffords!
llvm-svn: 103346
|
| |
|
|
|
|
|
|
| |
whether the extract instructions are available.
rdar://7956878
llvm-svn: 103277
|
| |
|
|
| |
llvm-svn: 103276
|
| |
|
|
| |
llvm-svn: 103271
|
| |
|
|
|
|
| |
patch by Peter Housel!
llvm-svn: 103267
|
| |
|
|
|
|
| |
slot is sufficiently aligned. Use VLDMD / VSTMD otherwise.
llvm-svn: 103235
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
instruction, rather than a location near where the new instruction
is being inserted.
llvm-svn: 103232
|