making trampolines more portable

Duncan Sands wrote:
> is it important for you to have portable bitcode (i.e. the trampoline
> size as some kind of symbolic constant, maybe via a global or an
> intrinsic) that works on all targets or would it be enough to have the
> LLVM info for the target expose the trampoline size, so when generating
> IR for a target X you would query the method for target X and if it
> returns "12 bytes" you would output an alloca of 12 bytes.

I'd prefer the former, but the latter is clearly much better than
having to guess.

> right now if you want to call external functions
> (for example) you need to know target details in order to generate IR
> that conforms to the target ABI. Just pointing out that it is hard to
> generate target independent bitcode that does non-trivial things.

Hmm... sounds like my intention to use LLVM bitcode as a portable
intermediate code is doomed, then. I had hoped that the "V" in LLVM
gave me more target-independence than that. I wouldn't necessarily
have expected this to work for entirely arbitrary ABIs, but I'd hoped
that it would have at least abstracted away the target calling conventions
for C functions.

Best regards,
Eric

Hi Eric,

Hmm... sounds like my intention to use LLVM bitcode as a portable
intermediate code is doomed, then. I had hoped that the "V" in LLVM
gave me more target-independence than that. I wouldn't necessarily
have expected this to work for entirely arbitrary ABIs, but I'd hoped
that it would have at least abstracted away the target calling conventions
for C functions.

for some ABI's the way a parameter is passed can depend on C type
information that there is no good way to represent in LLVM. This
is why (for the moment) front-ends are required to take care of
producing LLVM function declarations that conform with the ABI.
There is a plan to have a generic ABI library which makes it easy
for front-ends to do this.

Ciao,

Duncan.