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
On Wed, Jun 17, 2009 at 3:12 PM, Eric Smith<eric at brouhaha.com> wrote:> 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.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.