search for: stwu

...How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of stwu should get matched with the given pre_store. But I am confused as to how "ptroff" and "ptrreg" get matched with "memri" used in STWU? For reference[1] memri is defined as: d...

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat pre_store" get matched with those of memri. It is defined with operand types as: let MIOperandInfo = (ops dispRI:$imm, ptr_rc_nor0:$reg); while Pat is defined as: def...

Hi Anitha, memri is just describing that the address contains two components, an immediate and a register, and how to handle them in the instruction printer. The STWU expects a memri operand, and that is what is passed from the Pat. Hope that helps, Sam On 07/04/2013 10:19, Anitha B Gollamudi wrote: > Hi, > > > How do "Pat" operands get matched? I am trying to follow the example > given in http://llvm.org/docs/CodeGenerator.html#sele...

...l as an old C version of the SPEC97 tomcatv benchmark I have laying around. So it seems both 32-bit and 64-bit can call into shared libs. Not to say I haven't seen some code gen warts (using -O3). :) >From hello.s: main: mflr 0 stw 31, -4(1) stw 0, 4(1) stwu 1, -16(1) lis 3, .Lstr at ha mr 31, 1 la 3, .Lstr at l(3) bl puts li 3, 0 addi 1, 1, 16 lwz 0, 4(1) lwz 31, -4(1) mtlr 0 blr By the strict letter of the 32-bit ABI, the save and restore of r31 at a negative offset of...

...rch/ppc/crt0.S # -# void _start(void) -# { -# /* Divine up argc, argv, and envp */ -# environ = envp; -# exit(main(argc, argv, envp)); -# } -# .text .align 4 .type _start,@function .globl _start _start: - lwz 3,0(1) - addi 4,1,4 - addi 5,1,8 - slwi 0,3,2 - add 5,5,0 - li 0,0 - stwu 0,-16(1) - lis 9,environ@ha - stw 5,environ@l(9) - bl main - bl exit + mr 3,1 + li 4,0 + bl __libc_init .size _start,.-_start -- USB is for mice, FireWire is for men! sUse lINUX ag, n?RNBERG

On Tue, 2012-05-01 at 17:47 -0500, Hal Finkel wrote: > By default it should build for > whatever the current host is (no special flags required). To > specifically build for something else, use: > -ccc-host-triple powerpc64-unknown-linux-gnu > or > -ccc-host-triple powerpc-unknown-linux-gnu So LLVM isn't biarch capable? Meaning one LLVM compiler cannot generate both

...rk I have laying around. > So it seems both 32-bit and 64-bit can call into shared libs. > > Not to say I haven't seen some code gen warts (using -O3). :) > > From hello.s: > > main: > mflr 0 > stw 31, -4(1) > stw 0, 4(1) > stwu 1, -16(1) > lis 3, .Lstr at ha > mr 31, 1 > la 3, .Lstr at l(3) > bl puts > li 3, 0 > addi 1, 1, 16 > lwz 0, 4(1) > lwz 31, -4(1) > mtlr 0 > blr > > By the strict letter of the 32-b...

On Tue, 01 May 2012 17:23:07 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote: > On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > > LLVM/clang now will build in the normal way (./configure; make > > install) on PPC (you'll need at least the 3.1 release candidate (or > > trunk)). I generally build on my PPC64 hosts with: > > make ENABLE_OPTIMIZED=1

...ARCHOBJS)) + +archclean: diff --git a/usr/klibc/arch/ppc/crt0.S b/usr/klibc/arch/ppc/crt0.S new file mode 100644 index 0000000..85b6dca --- /dev/null +++ b/usr/klibc/arch/ppc/crt0.S @@ -0,0 +1,23 @@ +# +# arch/ppc/crt0.S +# + + .text + .align 4 + .type _start, at function + .globl _start +_start: + stwu 1,-16(1) + addi 3,1,16 + /* + * the SVR4abippc.pdf specifies r7 as a pointer to + * a termination function point + * However, Section 8.4.1 of the LSB API docs say that + * The value to be placed into register r7, the termination + * function pointer, is not passed to the process. + * So we s...

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at: