o Parallel addition and subtraction, signed/unsigned
o Miscellaneous operations: QADD, QDADD, QSUB, QDSUB
o Unsigned sum of absolute differences [and accumulate]: USAD8, USADA8
o Signed/Unsigned saturate: SSAT, SSAT16, USAT, USAT16
o Signed multiply accumulate long (halfwords): SMLAL<x><y>
o Signed multiply accumulate/subtract [long] (dual): SMLAD[x], SMLALD[X], SMLSD[X], SMLSLD[X]
o Signed dual multiply add/subtract [long]: SMUAD[X], SMUSD[X]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97276 91177308-0d34-0410-b5e6-96231b3b80d8
- Function uses all scratch registers AND
- Function does not use any callee saved registers AND
- Stack size is too big to address with immediate offsets.
In this case a register must be scavenged to calculate the address of a stack
object, and the scavenger needs a spare register or emergency spill slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97071 91177308-0d34-0410-b5e6-96231b3b80d8
greater-than-or-equal SELECT_CCs to NEON vmin/vmax instructions. This is
only allowed when UnsafeFPMath is set or when at least one of the operands
is known to be nonzero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97065 91177308-0d34-0410-b5e6-96231b3b80d8
memory from three or four registers and VST2 (multiple two-element structures)
which stores to memory from two double-spaced registers.
A8.6.391 & A8.6.393
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97018 91177308-0d34-0410-b5e6-96231b3b80d8
three or four registers and VLD2 (multiple two-element structures) which loads
memory into two double-spaced registers.
A8.6.307 & A8.6.310
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96980 91177308-0d34-0410-b5e6-96231b3b80d8
126.gcc nightly tests. These failures uncovered latent bugs that machine DCE
could remove one half of a stack adjust down/up pair, causing PEI to assert.
This update fixes that, and the tests now pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96822 91177308-0d34-0410-b5e6-96231b3b80d8
value.
Thumb2 uses the tADJCALLSTACK* instructions, and doesn't need t2 versions, so
remove the FIXME entry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96817 91177308-0d34-0410-b5e6-96231b3b80d8
o signed/unsigned add/subtract
o signed/unsigned halving add/subtract
o unsigned sum of absolute difference [and accumulate]
o signed/unsigned saturate
o signed multiply accumulate/subtract [long] dual
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96795 91177308-0d34-0410-b5e6-96231b3b80d8
handled in ARMInstPrinter.cpp.
And added PLD/PLDW/PLI (Preload Data/Instruction) for disassembly only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96719 91177308-0d34-0410-b5e6-96231b3b80d8
for ARM to just check if a function has a FP to determine if it's safe
to simplify the stack adjustment pseudo ops prior to eliminating frame
indices. Allow targets to override the default behavior and does so for ARM
and Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96634 91177308-0d34-0410-b5e6-96231b3b80d8
since it has no pattern, there's not much point in distinguishing an "N2VS"
class for intrinsics anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96525 91177308-0d34-0410-b5e6-96231b3b80d8
* Use "S" abbreviation for scalar single FP registers in class and pattern
names, instead of keeping the "D" (for "double") abbreviation and tacking on
an "s" elsewhere in the name.
* Move the scalar single FP register classes and patterns to be more
consistent with other definitions in the file.
* Rename "VNEGf32d" definition to "VNEGfd" for consistency.
* Deleted the N2VDIntsPat pattern; N2VSPat is good enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96521 91177308-0d34-0410-b5e6-96231b3b80d8
B6.1.8 RFE Return From Exception loads the PC and the CPSR from the word at the
specified address and the following word respectively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96519 91177308-0d34-0410-b5e6-96231b3b80d8
to have the predicate on the pattern itself instead. Support for the new
ISel. Remove definitions of CarryDefIsUnused and CarryDefIsUsed since they are
no longer used anywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96384 91177308-0d34-0410-b5e6-96231b3b80d8
They won't work with the new ISel mechanism, as Requires predicates are no
longer allowed to reference the node being selected. Moving the predicate to
the patterns instead solves the problem.
This patch handles ARM mode. Thumb2 will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96381 91177308-0d34-0410-b5e6-96231b3b80d8
branch in ARM v4 code, since it gets clobbered by the return address before
it is used. Instead of adding a new register class containing all the GPRs
except LR, just use the existing tGPR class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96360 91177308-0d34-0410-b5e6-96231b3b80d8
We could almost use a multiclass for the signed/unsigned instructions, but
there are only 6 of them so I guess it's not worth it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96297 91177308-0d34-0410-b5e6-96231b3b80d8
IsLegalToFold and IsProfitableToFold. The generic version of the later simply checks whether the folding candidate has a single use.
This allows the target isel routines more flexibility in deciding whether folding makes sense. The specific case we are interested in is folding constant pool loads with multiple uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96255 91177308-0d34-0410-b5e6-96231b3b80d8
created. This ensures it's updated at all time. It means targets which perform
dynamic stack alignment would know whether it is required and whether frame
pointer register cannot be made available register allocation.
This is a fix for rdar://7625239. Sorry, I can't create a reasonably sized test
case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96069 91177308-0d34-0410-b5e6-96231b3b80d8
Plus add two formats: MiscFrm and ThumbMiscFrm. Some of the for disassembly
only instructions are changed from Pseudo Format to MiscFrm Format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96032 91177308-0d34-0410-b5e6-96231b3b80d8
into TargetOpcodes.h. #include the new TargetOpcodes.h
into MachineInstr. Add new inline accessors (like isPHI())
to MachineInstr, and start using them throughout the
codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95687 91177308-0d34-0410-b5e6-96231b3b80d8
tMOVCCi pattern only valid for low registers, as the Thumb1 mov immediate to
register instruction only works with low registers. Allowing high registers
for the instruction resulted in the assembler choosing the wide (32-bit)
encoding for the mov, but LLVM though the instruction was only 16 bits wide,
so offset calculations for constant pools became incorrect, leading to
out of range constant pool entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95686 91177308-0d34-0410-b5e6-96231b3b80d8
The 'R' suffix means the to-integer operations use the rounding mode specified
by the FPSCR, encoded as Inst{7} = 0.
A8.6.295
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95584 91177308-0d34-0410-b5e6-96231b3b80d8
the end of the instruction instead of expecting the caller to
do it. This currently causes the asm-verbose instruction
comments to be on the next line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95178 91177308-0d34-0410-b5e6-96231b3b80d8
than DEBUG_VALUE :( ) into the target indep AsmPrinter.cpp
file. This allows elimination of the
NO_ASM_WRITER_BOILERPLATE hack among other things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95177 91177308-0d34-0410-b5e6-96231b3b80d8
mccontext instead of having AsmPrinter do it. This allows other
types of MCStreamer's to be passed in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95155 91177308-0d34-0410-b5e6-96231b3b80d8
eliminate random "code emitter" stuff in Alpha, except for
the JIT path. Next up, remove the template cruft.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95131 91177308-0d34-0410-b5e6-96231b3b80d8
Even if they are suported by the core, they can be disabled
(this is just a configuration bit inside some register).
Allow unaligned memops on darwin and conservatively disallow them otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94889 91177308-0d34-0410-b5e6-96231b3b80d8
bit (Inst{22}) and the M bit (Inst{5}) should be left unspecified. For binary
format instructions, Inst{6} and Inst{4} need to specified for proper decodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94855 91177308-0d34-0410-b5e6-96231b3b80d8
runOnMachineFunction, and switch PPC to use EmitFunctionBody.
The two ppc asmprinters now don't heave to define
runOnMachineFunction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94722 91177308-0d34-0410-b5e6-96231b3b80d8
Move the X86 implementation of function body emission up to
AsmPrinter::EmitFunctionBody, which works by calling the virtual
EmitInstruction method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94716 91177308-0d34-0410-b5e6-96231b3b80d8
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94686 91177308-0d34-0410-b5e6-96231b3b80d8
Target independent isel should always pass along the "tail call" property. Change
target hook LowerCall's parameter "isTailCall" into a refernce. If the target
decides it's impossible to honor the tail call request, it should set isTailCall
to false to make target independent isel happy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94626 91177308-0d34-0410-b5e6-96231b3b80d8
Default HasSetDirective to true, since most targets have it.
The targets that claim to not have it probably do, or it is
spelled differently. These include Blackfin, Mips, Alpha, and
PIC16. All of these except pic16 are normal ELF targets, so
they almost certainly have it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94585 91177308-0d34-0410-b5e6-96231b3b80d8
AsmPrinter::SetupMachineFunction sets it. Note that systemz
and msp430 didn't. Yay for reduced inconsistency! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94510 91177308-0d34-0410-b5e6-96231b3b80d8
missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94164 91177308-0d34-0410-b5e6-96231b3b80d8
cannot be directly interchanged for comparisons against negated values.
Disable the CMN instructions for the time being.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94119 91177308-0d34-0410-b5e6-96231b3b80d8
I really want clients of the streamer to be able to say "emit this
64-bit integer" and have it get broken down right by the streamer.
I may change this in the future, we'll see how it works out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93934 91177308-0d34-0410-b5e6-96231b3b80d8
the two token accessor functions are declared consistently.
Modified the clients of MCAsmParser to reflect this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93916 91177308-0d34-0410-b5e6-96231b3b80d8
function can support dynamic stack realignment. That's a much easier question
to answer at instruction selection stage than whether the function actually
will have dynamic alignment prologue. This allows the removal of the
stack alignment heuristic pass, and improves code quality for cases where
the heuristic would result in dynamic alignment code being generated when
it was not strictly necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93885 91177308-0d34-0410-b5e6-96231b3b80d8
This makes a similar code dead in all the other targets, I'll clean it up
in a bit.
This also moves handling of lcomm up before acquisition of a section,
since lcomm never needs a section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93851 91177308-0d34-0410-b5e6-96231b3b80d8
simplify and commonize some of the asmprinter logic for globals.
This also avoids printing the MCSection for .zerofill, which broke
the llvm-gcc build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93843 91177308-0d34-0410-b5e6-96231b3b80d8
1. TargetLoweringObjectFileMachO should decide if something
goes in zerofill instead of having every target do it.
2. TargetLoweringObjectFileMachO should assign said symbols to
the right MCSection, the asmprinters should just emit to the
right section.
3. Since all zerofill stuff goes through mcstreamer anymore,
MAI can have a bool "haszerofill" instead of having the textual
directive to emit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93838 91177308-0d34-0410-b5e6-96231b3b80d8
the various MOV (register) instructions (16-bit Thumb), including tBRIND (the
indirect branch). Instead of '1', it should be specified as '?', because GPR
only specifies the register class, which includes both hi-and-lo registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93759 91177308-0d34-0410-b5e6-96231b3b80d8
with the rest of the assembly output, is easier to read, and matches the
expected output for gcc's Neon tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93703 91177308-0d34-0410-b5e6-96231b3b80d8
remove it and change all the code that prints MCSymbols to use
<< instead, which is much simpler and cleaner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93695 91177308-0d34-0410-b5e6-96231b3b80d8
adding an "i" to the suffix, indicating that the elements are integers, is
accepted but not part of the standard syntax. This helps us pass a few more
of the Neon tests from gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93677 91177308-0d34-0410-b5e6-96231b3b80d8
and add an explicit ForcePrivate argument.
Switch FunctionEHFrameInfo to be MCSymbol based instead of string based.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93646 91177308-0d34-0410-b5e6-96231b3b80d8
the new ParseInstruction method just parses and returns a list of
target operands. A new MatchInstruction interface is used to
turn the operand list into an MCInst.
This requires new/deleting all the operands, but it also gives
targets the ability to use polymorphic operands if they want to.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93469 91177308-0d34-0410-b5e6-96231b3b80d8
This is consistent with llvm-gcc's arm/constraints.md.
Certain instructions (e.g. CBZ, CBNZ) require a low register, even in Thumb2
mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93436 91177308-0d34-0410-b5e6-96231b3b80d8
An unaligned ldr causes a trap, and is then emulated by the kernel with
awesome performance. The darwin kernel does not emulate unaligned ldm/stm
Thumb2 instructions, so don't generate them.
This fixes the miscompilation of Multisource/Applications/JM/lencod for Thumb2.
Generating unaligned ldr/str pairs from a 16-bit aligned memcpy is probably
also a bad idea, but that is beyond the scope of this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93393 91177308-0d34-0410-b5e6-96231b3b80d8
instead of returning it in an std::string. Based on this change:
1. Change TargetLoweringObjectFileCOFF::getCOFFSection to take a StringRef
2. Change a bunch of targets to call makeNameProper with a smallstring,
making several of them *much* more efficient.
3. Rewrite Mangler::makeNameProper to not build names and then prepend
prefixes, not use temporary std::strings, and to avoid other crimes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93298 91177308-0d34-0410-b5e6-96231b3b80d8
It was only being used by instructions with the t_addrmode_sp addressing mode,
and that is pattern matched in a way that guarantees SP is used. There is
never any register allocation done from this class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93280 91177308-0d34-0410-b5e6-96231b3b80d8
clear what information these functions are actually using.
This is also a micro-optimization, as passing a SDNode * around is
simpler than passing a { SDNode *, int } by value or reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92564 91177308-0d34-0410-b5e6-96231b3b80d8
mainly used in debugging and/or assert situations. It should make the compiler
and the static analyzer stop nagging us about them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92181 91177308-0d34-0410-b5e6-96231b3b80d8
return partial registers. This affected the back-end lowering code some.
Also patch up some places I missed before in the "get" functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91880 91177308-0d34-0410-b5e6-96231b3b80d8
MI was not being used but it was also not being deleted, so it was kept in the garbage list. The memory itself was freed once the function code gen was done.
Once in a while the codegen of another function would create an instruction on the same address. Adding it to the garbage group would work once, but when another pointer was added it would cause an assert as "Cache" was about to be pushed to Ts.
For a patch that make us detect problems like this earlier, take a look at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091214/092758.html
With that patch we assert as soon and the new instruction is added to the garbage set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91691 91177308-0d34-0410-b5e6-96231b3b80d8
The change in SelectionDAGBuilder is needed to allow using bitcasts to convert
between f64 (the default type for ARM "d" registers) and 64-bit Neon vector
types. Radar 7457110.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91649 91177308-0d34-0410-b5e6-96231b3b80d8
remove start/finishGVStub and the BufferState helper class from the
MachineCodeEmitter interface. It has the side-effect of not setting the
indirect global writable and then executable on ARM, but that shouldn't be
necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91464 91177308-0d34-0410-b5e6-96231b3b80d8
just issues an error for the moment. The front end won't yet generate these
intrinsics for ARM, so this is behind the scenes until complete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91200 91177308-0d34-0410-b5e6-96231b3b80d8
both source operands. In the canonical form, the 2nd operand is changed to an
undef and the shuffle mask is adjusted to only reference elements from the 1st
operand. Radar 7434842.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90417 91177308-0d34-0410-b5e6-96231b3b80d8
For VMOVv*i[16,32], op bit is don't care, and some cmode bits vary depending on
the immediate values.
Ref: Table A7-15 Modified immediate values for Advanced SIMD instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90173 91177308-0d34-0410-b5e6-96231b3b80d8
for all the processors where I have tried it, and even when it might not help
performance, the cost is quite low. The opportunities for duplicating
indirect branches are limited by other factors so code size does not change
much due to tail duplicating indirect branches aggressively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90144 91177308-0d34-0410-b5e6-96231b3b80d8
Make tail duplication of indirect branches much more aggressive (for targets
that indicate that it is profitable), based on further experience with
this transformation. I compiled 3 large applications with and without
this more aggressive tail duplication and measured minimal changes in code
size. ("size" on Darwin seems to round the text size up to the nearest
page boundary, so I can only say that any code size increase was less than
one 4k page.) Radar 7421267.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89814 91177308-0d34-0410-b5e6-96231b3b80d8
than doing the same via constpool:
1. Load from constpool costs 3 cycles on A9, movt/movw pair - just 2.
2. Load from constpool might stall up to 300 cycles due to cache miss.
3. Movt/movw does not use load/store unit.
4. Less constpool entries => better compiler performance.
This is only enabled on ELF systems, since darwin does not have needed
relocations (yet).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89720 91177308-0d34-0410-b5e6-96231b3b80d8
way for each TargetJITInfo subclass to allocate its own stubs. This
means stubs aren't as exactly-sized anymore, but it lets us get rid of
TargetJITInfo::emitFunctionStubAtAddr(), which lets ARM and PPC
support the eager JIT, fixing http://llvm.org/PR4816.
* Rename the JITEmitter's stub creation functions to describe the kind
of stub they create. So far, all of them create lazy-compilation
stubs, but they sometimes get used when far-call stubs are needed.
Fixing http://llvm.org/PR5201 will involve fixing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89715 91177308-0d34-0410-b5e6-96231b3b80d8
Note that "hasDotLocAndDotFile"-style debug info was already broken;
people wanting this functionality should implement it in the
AsmPrinter/DwarfWriter code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89711 91177308-0d34-0410-b5e6-96231b3b80d8
It's probably better in the long run to replace the
indirect-GlobalVariable system. That'll be done after a subsequent
patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89708 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the NEON asm printing so the "predicate" field is printed between the opcode and the data type suffix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89706 91177308-0d34-0410-b5e6-96231b3b80d8
VDUPLND and VDUPLNQ to derive from N2V instead of N2VDup. VDUPLND and VDUPLNQ
now expect op19_18 and op17_16 as the first two args.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89699 91177308-0d34-0410-b5e6-96231b3b80d8
constant pool ranges, as CPEIsInRange() makes conservative assumptions about
the potential alignment changes from branch adjustments. The verification,
on the other hand, runs after those branch adjustments are made, so the
effects on alignment are known and already taken into account. The sanity
check in verify should check the range directly instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89473 91177308-0d34-0410-b5e6-96231b3b80d8
assembly can confuse things utterly, as it's assumed that instructions in
inline assembly are 4 bytes wide. For Thumb mode, that's often not true,
so the calculations for when alignment padding will be present get thrown off,
ultimately leading to out of range constant pool entry references. Making
more conservative assumptions that padding may be necessary when inline asm
is present avoids this situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89403 91177308-0d34-0410-b5e6-96231b3b80d8
fully specified at this level. Subclasses of NLdStLN can specify selective
bit(s) for Inst{7-4}, as is done for VLD[234]LN* and VST[234]LN* inside
ARMInstrNEON.td.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89377 91177308-0d34-0410-b5e6-96231b3b80d8
contents of the block to be duplicated. Use this for ARM Cortex A8/9 to
be more aggressive tail duplicating indirect branches, since it makes it
much more likely that they will be predicted in the branch target buffer.
Testcase coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89187 91177308-0d34-0410-b5e6-96231b3b80d8
0b1110 (ALways). This is so that the disassembler decoder can distinguish among
BX_RET, BRIND, and BXr9.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89000 91177308-0d34-0410-b5e6-96231b3b80d8
- If destination is a physical register and it has a subreg index, use the
sub-register instead.
This fixes PR5423.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88745 91177308-0d34-0410-b5e6-96231b3b80d8
target-specific AsmPrinters. Not all comments need DebugInfo.
Re-enable the line numbers comment test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88697 91177308-0d34-0410-b5e6-96231b3b80d8
slots. The AsmPrinter will use this information to determine whether to
print a spill/reload comment.
Remove default argument values. It's too easy to pass a wrong argument
value when multiple arguments have default values. Make everything
explicit to trap bugs early.
Update all targets to adhere to the new interfaces..
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@87022 91177308-0d34-0410-b5e6-96231b3b80d8
to directly follow the jump table. Move the layout changes to prior to any
constant island handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86999 91177308-0d34-0410-b5e6-96231b3b80d8
can only branch forward. To best take advantage of them, we'd like to adjust
the basic blocks around a bit when reasonable. This patch puts basics in place
to do that, with a super-simple algorithm for backwards jump table targets that
creates a new branch after the jump table which branches backwards. Real
heuristics for reordering blocks or other modifications rather than inserting
branches will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86791 91177308-0d34-0410-b5e6-96231b3b80d8
MachineRelocations, "stub" always refers to a far-call stub or a
load-a-faraway-global stub, so this patch adds "Far" to the term. (Other stubs
are used for lazy compilation and dlsym address replacement.) The variable was
also inconsistent between the positive and negative sense, and the positive
sense ("NeedStub") was more demanding than is accurate (since a nearby-enough
function can be called directly even if the platform often requires a stub).
Since the negative sense causes double-negatives, I switched to
"MayNeedFarStub" globally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86363 91177308-0d34-0410-b5e6-96231b3b80d8
except it doesn't care if the definitions' virtual registers differ. This is
used by machine LICM and other MI passes to perform CSE.
- Teach Thumb2InstrInfo::isIdentical() to check two t2LDRpci_pic are identical.
Since pc relative constantpool entries are always different, this requires it
it check if the values can actually the same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86328 91177308-0d34-0410-b5e6-96231b3b80d8
was wrong and too aggressive in the sense that DPSoRegFrm includes both constant
shifts (with Inst{4} = 0) and register controlled shifts (with Inst{4} = 1 and
Inst{7} = 0). The 'rr' fragment of the multiclass definitions actually means
register/register with no shift, see A8-11.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86319 91177308-0d34-0410-b5e6-96231b3b80d8
load of a GV from constantpool and then add pc. It allows the code sequence to
be rematerializable so it would be hoisted by machine licm.
- Add a late pass to break these pseudo instructions into a number of real
instructions. Also move the code in Thumb2 IT pass that breaks up t2MOVi32imm
to this pass. This is done before post regalloc scheduling to allow the
scheduler to proper schedule these instructions. It also allow them to be
if-converted and shrunk by later passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86304 91177308-0d34-0410-b5e6-96231b3b80d8
will not accept negative values for these. LLVM's default operand printing
sign extends values, so that valid unsigned values appear as negative
immediates. Print all VMOV immediate operands as hex values to resolve this.
Radar 7372576.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86301 91177308-0d34-0410-b5e6-96231b3b80d8
aggressive testing of dynamic stack alignment.
Note that this is off by default, and enabled for LLCBETA nightly results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86064 91177308-0d34-0410-b5e6-96231b3b80d8
The KILL pseudo-instruction may survive to the asm printer pass, just like the IMPLICIT_DEF. Print the KILL as a comment instead of just leaving a blank line in the output.
With -asm-verbose=0, a blank line is printed, like IMPLICIT?DEF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86041 91177308-0d34-0410-b5e6-96231b3b80d8
is unconditional. Making it still use the libcall when optimizing for size
would be a good adjustment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85675 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Dunbar.
- Reordered the fields in the ARMOperand Mem struct to make the struct smaller.
Making bool's into 1 bit fields and put the MCExpr* fields adjacent to each
other.
- Fixed a number of places in ARMAsmParser.cpp so they have doxygen comments.
- Change the name of ARMAsmParser::ParseRegister() to MaybeParseRegister and
added the bool ParseWriteBack parameter.
- Changed ARMAsmParser::ParseMemory() to call MaybeParseRegister().
- Added ARMAsmParser::ParseMemoryOffsetReg to factor out parsing the offset of a
memory operand. And use it for both parsing both preindexed and post indexing
addressing forms in ARMAsmParser::ParseMemory.
- Changed the first argument to ParseShift() to a reference.
- Changed ParseShift() to check for Rrx first and return to reduce nesting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85632 91177308-0d34-0410-b5e6-96231b3b80d8
void f (int a1, int a2, int a3, int a4, int a5,...)
In ARMTargetLowering::LowerFormalArguments if the function has 4 or
more regular arguments we used to set VarArgsFrameIndex using an
offset of 0, which is only correct if the function has exactly 4
regular arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85590 91177308-0d34-0410-b5e6-96231b3b80d8
bunch of associated comments, because it doesn't have anything to do
with DAGs or scheduling. This is another step in decoupling MachineInstr
emitting from scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85517 91177308-0d34-0410-b5e6-96231b3b80d8
use it to control tail merging when there is a tradeoff between performance
and code size. When there is only 1 instruction in the common tail, we have
been merging. That can be good for code size but is a definite loss for
performance. Now we will avoid tail merging in that case when the
optimization level is "Aggressive", i.e., "-O3". Radar 7338114.
Since the IfConversion pass invokes BranchFolding, it too needs to know
the optimization level. Note that I removed the RegisterPass instantiation
for IfConversion because it required a default constructor. If someone
wants to keep that for some reason, we can add a default constructor with
a hard-wired optimization level.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85346 91177308-0d34-0410-b5e6-96231b3b80d8
default behind a command line option. This will enable better performance for
vectors on NEON enabled processors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85333 91177308-0d34-0410-b5e6-96231b3b80d8
Chris claims we should never have visibility_hidden inside any .cpp file but
that's still not true even after this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85042 91177308-0d34-0410-b5e6-96231b3b80d8
can access the hi regs. Our prologue and epilogue code doesn't know how to
properly handle save/restore of the hi regs, so things go badly when we alloc
them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84982 91177308-0d34-0410-b5e6-96231b3b80d8
a default value of zero. This is important for decoding the instructions.
Patch by Johnny Chen, with some changes from me, too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84730 91177308-0d34-0410-b5e6-96231b3b80d8
reasonable code like Codegen/ARM/2009-02-27-SpillerBug.ll, producing
identical output except for superior formatting of constant pool entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84582 91177308-0d34-0410-b5e6-96231b3b80d8
Leave Inst{11-8}, which represents the starting byte index of the extracted
result in the concatenation of the operands and is left unspecified.
Patch by Johnny Chen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84572 91177308-0d34-0410-b5e6-96231b3b80d8
appropriate restore location for the spill as well as perform the actual
save and restore.
The Thumb1 target uses this to make sure R12 is not clobbered while a spilled
scavenger register is live there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84554 91177308-0d34-0410-b5e6-96231b3b80d8
lowering stuff. We can now compile hello world to:
_main:
stm ,
mov r7, sp
sub sp, sp, #4
mov r0, #0
str r0,
ldr r0,
bl _printf
ldr r0,
mov sp, r7
ldm ,
Almost looks like arm code :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84542 91177308-0d34-0410-b5e6-96231b3b80d8
through mcinst lowering -> mcinstprinter, when llc is passed
the -enable-arm-mcinst-printer flag. Currently this
is very "aborty".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84530 91177308-0d34-0410-b5e6-96231b3b80d8
stack slots and giving them different PseudoSourceValue's did not fix the
problem of post-alloc scheduling miscompiling llvm itself.
- Apply Dan's conservative workaround by assuming any non fixed stack slots can
alias other memory locations. This means a load from spill slot #1 cannot
move above a store of spill slot #2.
- Enable post-alloc scheduling for x86 at optimization leverl Default and above.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84424 91177308-0d34-0410-b5e6-96231b3b80d8
I can see with the original code was that I forgot that this runs after
type legalization and hence the result type will always be i32. (Custom
legalization of EXTRACT_VECTOR_ELT is only enabled for vector types with
8- and 16-bit elements.)
Regarding the FIXME comment: any information about sign and zero-extension
should be captured by separate extension operations. The DAG combiner should
handle those to produce either VGETLANEu or VGETLANEs, and that seems to be
working now. If there are cases that we're missing, let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84218 91177308-0d34-0410-b5e6-96231b3b80d8
In the case where there are no good places to put constants and we fall back
upon inserting unconditional branches to make new blocks, allow all constant
pool references in range of those blocks to put constants there, even if that
means resetting the "high water marks" for those references. This will still
terminate because you can't keep splitting blocks forever, and in the bad
cases where we have to split blocks, it is important to avoid splitting more
than necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84202 91177308-0d34-0410-b5e6-96231b3b80d8
as expressions, code for parsing a few arm specific directives (still needs
the MCStreamer calls for these). Some clean up of the operand parsing code
and adding some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84201 91177308-0d34-0410-b5e6-96231b3b80d8
When ARMConstantIslandPass cannot find any good locations (i.e., "water") to
place constants, it falls back to inserting unconditional branches to make a
place to put them. My recent change exposed a problem in this area. We may
sometimes append to the same block more than one unconditional branch. The
symptoms of this are that the generated assembly has a branch to an undefined
label and running llc with -debug will cause a seg fault.
This happens more easily since my change to prevent CPEs from moving from
lower to higher addresses as the algorithm iterates, but it could have
happened before. The end of the block may be in range for various constant
pool references, but the insertion point for new CPEs is not right at the end
of the block -- it is at the end of the CPEs that have already been placed
at the end of the block. The insertion point could be out of range. When
that happens, the fallback code will always append another unconditional
branch if the end of the block is in range.
The fix is to only append an unconditional branch if the block does not
already end with one. I also removed a check to see if the constant pool load
instruction is at the end of the block, since that is redundant with
checking if the end of the block is in-range.
There is more to be done here, but I think this fixes the immediate problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84172 91177308-0d34-0410-b5e6-96231b3b80d8
Also fixed a couple of coding style things that crept in. And added more
to the temporary hacked up ARMAsmParser::MatchInstruction() method for testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84040 91177308-0d34-0410-b5e6-96231b3b80d8
multiple instructions, the expansion is done during selection so there is
no need to do anything special during legalization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84036 91177308-0d34-0410-b5e6-96231b3b80d8
be in a register. The previous use of ARM address mode 2 was completely
arbitrary and inappropriate for Thumb. Radar 7137468.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84022 91177308-0d34-0410-b5e6-96231b3b80d8
before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb. Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83916 91177308-0d34-0410-b5e6-96231b3b80d8
MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now. Radar 7291928.
The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it. There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code. The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range. On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted. The second CPE had
been in range but the newly inserted entry pushed it too far away. Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range. Etc.
Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references. In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs. This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it. This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs. This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.
To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion. The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses. This is a very simple change to the code and should not cause
any significant degradation in the results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83902 91177308-0d34-0410-b5e6-96231b3b80d8
lists. Changed ARMAsmParser::MatchRegisterName to return -1 instead of 0 on
errors so 0-15 values could be returned as register numbers. Also added the
rest of the arm register names to the currently hacked up version to allow more
testing. Some changes to ARMAsmParser::ParseOperand to give different errors
for things not yet supported and some additions to the hacked
ARMAsmParser::MatchInstruction to allow more testing for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83673 91177308-0d34-0410-b5e6-96231b3b80d8
