llvm dev - Aug 2004 - [LLVMdev] conditionally reduced intrinsics (llvm.syscall)

Well, the complexity only occurs on x86, other archs are simpler.  Since
this is not used much outside the c library, I can work around it in the
library and be satisifed with the simple case.

Oh, I suppose I should mention what I was working on.  I made a syscall
intrinsic with codegen for linux/x86.  It seemed a missing peice in
having a pure llvm compiled userland (mostly, being able to have a full
bytecode glibc).

On x86, syscalls with 5 and few args are passed in registers, but
for
>6, all args (except syscall number) go in a memory block passed as the
first argutment.  I wasn't sure if when I generate code I could safely
manipulate the stack pointer (that it was gaurentied to be correct) at
the point I was inserting instructions.  If so, then I can add the >6
case directly to the codegen.

Anyway, attached is  some sample assembly output from a simple test
(write).  There are some corners to clean up (the codegen only accepts
ints for args to a syscall, which requires casting).

Andrew



On Sat, 2004-08-21 at 23:07, Brian R. Gaeke wrote:
> > Ok, I am developing an intrinsic instruction and I have the codegen
> > working (and tested).  However, some of the more complex cases of the
> > intrinsic are reducable to LLVM + simpler cases of the intrinsic.  How
> > would I go about conditionally reducing the intrinsic?  I could deal
> > with the issue in the codegen, but that gets ugly quickly.
> > 
> > Andrew
> 
> I suppose you could do an LLVM->LLVM lowering pass which reduces the
> complex cases to the simple cases. This would then allow you to use
> the redundancy-elimination passes like LICM to clean up the resulting
> code.
> 
> -Brian
-------------- next part --------------
target endian = little
target pointersize = 32
	%struct..TorRec = type { int, void ()* }
	%struct.TorRec = type { int, void ()* }
	%struct.timeval = type { int, int }
	%typedef.__sigset_t = type { [32 x uint] }
	%typedef.fd_set = type { [32 x int] }
	%typedef.pthread_mutexattr_t = type { int }
	%union.nfsctl_res3. = type opaque
%.str_1 = internal constant [13 x sbyte] c"Hello World\0A\00"		;
<[13 x sbyte]*> [#uses=1]
%errno = internal global int 0		; <int*> [#uses=1]
%Initialized.0__ = internal global bool false		; <bool*> [#uses=2]

implementation   ; Functions:

int %main() {
entry:
	%tmp.1.i = load bool* %Initialized.0__		; <bool> [#uses=1]
	br bool %tmp.1.i, label %__main.entry, label %endif.0.i

endif.0.i:		; preds = %entry
	store bool true, bool* %Initialized.0__
	br label %__main.entry

__main.entry:		; preds = %entry, %endif.0.i
	%tmp.1 = call uint %write( int 1, sbyte* getelementptr ([13 x sbyte]* %.str_1,
int 0, int 0), uint 12 )		; <uint> [#uses=0]
	ret int 0
}

internal uint %write(int %fd, sbyte* %voidp, uint %size) {
entry:
	%tmp.3 = cast sbyte* %voidp to int		; <int> [#uses=1]
	%ret.i = call int (int, ...)* %llvm.syscall( int 4, int %fd, int %tmp.3, uint
%size )		; <int> [#uses=4]
	%tmp.7 = cast int %ret.i to uint		; <uint> [#uses=1]
	%tmp.8 = setgt uint %tmp.7, 4294967170		; <bool> [#uses=3]
	br bool %tmp.8, label %then, label %endif

then:		; preds = %entry
	%tmp.11 = sub int 0, %ret.i		; <int> [#uses=1]
	store int %tmp.11, int* %errno
	%r.01 = select bool %tmp.8, int -1, int %ret.i		; <int> [#uses=1]
	%tmp.132 = cast int %r.01 to uint		; <uint> [#uses=1]
	ret uint %tmp.132

endif:		; preds = %entry
	%r.0 = select bool %tmp.8, int -1, int %ret.i		; <int> [#uses=1]
	%tmp.13 = cast int %r.0 to uint		; <uint> [#uses=1]
	ret uint %tmp.13
}

declare int %llvm.syscall(int, ...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20040822/e275108d/attachment.sig>

Hi,
> Oh, I suppose I should mention what I was working on.  I made a syscall
> intrinsic with codegen for linux/x86.  It seemed a missing peice in
> having a pure llvm compiled userland (mostly, being able to have a full
> bytecode glibc).
This sounds like a good and useful thing.  Are you coordinating
your work with John Criswell?
> Well, the complexity only occurs on x86, other archs are simpler.  Since
> this is not used much outside the c library, I can work around it in the
> library and be satisifed with the simple case.
Architecture-specific calling conventions are typically dealt with
in the various target support libraries (lib/Target/*).

I think what you should do for the X86 codegen is to use the
MachineFrameInfo to build your memory block and add the >6 case
"directly to the codegen", as you say.  I recommend against inserting
MachineInstrs that explicitly manipulate the stack pointer; you are
likely to fall afoul of the PrologEpilogInserter and register
allocator.

-Brian

On Sun, 22 Aug 2004, Brian R. Gaeke wrote:
> > Well, the complexity only occurs on x86, other archs are simpler. 
Since
> > this is not used much outside the c library, I can work around it in
the
> > library and be satisifed with the simple case.
>
> Architecture-specific calling conventions are typically dealt with
> in the various target support libraries (lib/Target/*).
>
> I think what you should do for the X86 codegen is to use the
> MachineFrameInfo to build your memory block and add the >6 case
> "directly to the codegen", as you say.  I recommend against
inserting
> MachineInstrs that explicitly manipulate the stack pointer; you are
> likely to fall afoul of the PrologEpilogInserter and register
> allocator.
A good way to figure out how to do this is to look at the code that is
generated for the alloca instruction in the X86 backend.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/