matching code that is not currently auto-generated by tblgen, e.g. X86
addressing mode. Selection routines for complex patterns can return multiple operands, e.g. X86 addressing mode returns 4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24634 91177308-0d34-0410-b5e6-96231b3b80d8
def SHL8rCL : I<0xD2, MRM4r, (ops R8 :$dst, R8 :$src),
"shl{b} {%cl, $dst|$dst, %CL}",
[(set R8:$dst, (shl R8:$src, CL))]>, Imp<[CL],[]>;
This generates a CopyToReg operand and added its 2nd result to the shl as
a flag operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24557 91177308-0d34-0410-b5e6-96231b3b80d8
changes allow us to generate the following code:
_foo:
li r2, 0
lvx v0, r2, r3
vaddfp v0, v0, v0
stvx v0, r2, r3
blr
for this llvm:
void %foo(<4 x float>* %a) {
entry:
%tmp1 = load <4 x float>* %a
%tmp2 = add <4 x float> %tmp1, %tmp1
store <4 x float> %tmp2, <4 x float>* %a
ret void
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24534 91177308-0d34-0410-b5e6-96231b3b80d8
packed types with an element count of 1, although more generic support is
coming. This allows LLVM to turn the following code:
void %foo(<1 x float> * %a) {
entry:
%tmp1 = load <1 x float> * %a;
%tmp2 = add <1 x float> %tmp1, %tmp1
store <1 x float> %tmp2, <1 x float> *%a
ret void
}
Into:
_foo:
lfs f0, 0(r3)
fadds f0, f0, f0
stfs f0, 0(r3)
blr
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24416 91177308-0d34-0410-b5e6-96231b3b80d8
this and have it in about the same form, I think this makes sense.
on X86, you do a RDTSC (64bit result, from any ring since the P5MMX)
on Alpha, you do a RDCC
on PPC, there is a sequence which may or may not work depending on how things
are setup by the OS. Or something like that. Maybe someone who knows PPC
can add support. Something about the time base register.
on Sparc, you read %tick, which in some solaris versions (>=8) is readable by
userspace
on IA64 read ar.itc
So I think the ulong is justified since all of those are 64bit.
Support is slighly flaky on old chips (P5 and lower) and sometimes
depends on OS (PPC, Sparc). But for modern OS/Hardware (aka this decade),
we should be ok.
I am still not sure what to do about lowering. I can either see a lower to 0, to
gettimeofday (or the target os equivalent), or loudly complaining and refusing to
continue.
I am commiting an Alpha implementation. I will add the X86 implementation if I
have to (I have use of it in the near future), but if someone who knows that
backend (and the funky multi-register results) better wants to add it, it would
take them a lot less time ;)
TODO: better lowering and legalizing, and support more platforms
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24299 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't support .asciz, just set AscizDirective to null in your asmprinter.
This compiles C strings to:
l1__2E_str_1: ; '.str_1'
.asciz "foo"
instead of:
l1__2E_str_1: ; '.str_1'
.ascii "foo\000"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24271 91177308-0d34-0410-b5e6-96231b3b80d8
This eliminates the vector, allows constant time removal of a node from
a graph, and makes iteration over the all nodes list stable when adding
nodes to the graph.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24262 91177308-0d34-0410-b5e6-96231b3b80d8
allocated. Further, in the common case where a node has a single value, just
reference an element from a small array. This is a small compile-time wi.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24250 91177308-0d34-0410-b5e6-96231b3b80d8
This saves 12 bytes from SDNode, but doesn't speed things up substantially
(our graphs apparently already fit within the cache on my g5). In any case
this reduces memory usage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24248 91177308-0d34-0410-b5e6-96231b3b80d8
alignment information appropriately. Includes code for PowerPC to support
fixed-size allocas with alignment larger than the stack. Support for
arbitrarily aligned dynamic allocas coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24224 91177308-0d34-0410-b5e6-96231b3b80d8
