of testing for its presence at cmake time.
This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126068 91177308-0d34-0410-b5e6-96231b3b80d8
in the right direction. It eliminated some hacks and will unblock codegen
work. But it's far from being done. It doesn't reject illegal expressions,
e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123369 91177308-0d34-0410-b5e6-96231b3b80d8
difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
additional pipeline stall. So it's frequently better to single codegen
vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
vmla + vmla is very bad. But this isn't ideal either:
vmul
vadd
vmla
Instead, we want to expand the second vmla:
vmla
vmul
vadd
Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
faster.
Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.
A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
vmla / vmls will trigger one of the special hazards.
Work in progress, only A+B are enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
the eqv X86 class.
For now, I split the ELFARMAsmBackend from the DarwinARMAsmBackend
(also mimicking X86)
Tested against -r115126
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115129 91177308-0d34-0410-b5e6-96231b3b80d8
llc now recognizes the "intent" to support MC/obj emission for ARM, but
given that they are all stubs, it asserts on --filetype=obj --march=arm
Patch by Jason Kim.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114856 91177308-0d34-0410-b5e6-96231b3b80d8
bit (we're not trying to build a shared library yet) and generating
the X86GenEDInfo.inc and ARMGenEDInfo.inc files as necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101188 91177308-0d34-0410-b5e6-96231b3b80d8
Place the LSDA into the TEXT section for ARM platforms. This involves making the
encoding indirect, pcrel, and sdata4 instead of an absolute pointer. The
references to the type infos are then non-lazy pointers. Revision 98019 changed
the encoding of non-lazy pointers to add the symbol to the non-lazy pointer
definition if it's a local symbol (otherwise, it's external and set to '0' so
that the loader can adjust it to the real value). This paved the way for this
change to work on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98068 91177308-0d34-0410-b5e6-96231b3b80d8
that have that constraint. This is currently just assigning a fixed set of
registers, and it only handles VLDn for n=2,3,4 with DPR registers.
I'm going to expand it to handle more operations next; we can make it smarter
once everything is working correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78256 91177308-0d34-0410-b5e6-96231b3b80d8
