Eli Friedman wrote:
> Also, for lack of an intrinsic, there's a relatively easy workaround:
> you can declare a global containing the correct size, then link in a
> small target-specific .bc with the definition right before code
> generation.
So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide it in my software, I'll have to track any changes that happen in LLVM-generated trampolines in the future.
My point is that LLVM is unnecessarily requiring software that generates LLVM bitcode to know things about the target, which defeats the purpose of the "V" in LLVM.
I should be able to generate a .bc file, and email it to someone, and they should be able to use it, all without my having any clue whatsoever about what target architecture they're using.
Eric
I didn't say we wouldn't accept a patch. It's just that up until now
nobody has particularly cared because trampolines aren't used very
much.
-Eli
Hi Eric,
> Also, for lack of an intrinsic, there's a relatively easy workaround:
> you can declare a global containing the correct size, then link in a
> small target-specific .bc with the definition right before code
> generation.
So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide it in my software, I'll have to track any changes that happen in LLVM-generated trampolines in the future.
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 should be able to generate a .bc file, and email it to someone, and they should be able to use it, all without my having any clue whatsoever about what target architecture they're using.
That would be nice, but 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.
Ciao,
Duncan.