[cfe-dev] Passing StructType arguments directly

[David Chisnall]

At the most EuroLLVM2011, Jin-Gu Kang presented this:

http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-MoreTargetIndependentLLVMBitcode.pdf

Unfortunately, the slides don't provide any links to the code or contact information.  Maybe someone who attended the conference could give some more information, because this sounds like it's pretty much exactly what you want...

David

On 23 Sep 2011, at 10:56, Renato Golin wrote:

> On 23 September 2011 04:18, David Meyer <pdox at google.com> wrote:
>> Sandeep,
>> 
>> Theoretically, in the future, the official IRT would be built by
>> PNaCl, so that any native code would need to match our ABI.
>> Furthermore, if we can demonstrate that we can match the performance
>> and reliability of the nacl-gcc toolchain, we could legitimately
>> require every vendor to switch to PNaCl.
> 
> Hi David,
> 
> I find it difficult to believe that you can get a target-independent
> PCS *and* improve performance.
> 
> As Sandeep said, ARM has it's own sub-architectures (APCS, AAPCS,
> AAPCS VFP) which are more similar to AMD64 than x86. The only way to
> be truly independent is to follow the base standard, which is to put
> everything on the stack, and that, well, produces very bad performance
> (or at least, is harder for the compiler to optimise, I'd guess).
> 
> This topic was discussed in the European meeting, and I've heard two
> options to link the language-specific features with target-specific
> ABI:
> 
> 1. To annotate IR
> 
> This is not the best idea ever, and many optimizations can remove
> metadata and break the lowering. The alternative would be to create
> special keywords (like values_in_regs_pcs, values_in_vfp_regs_pcs,
> etc) to become a bit more platform-independent. That would work on
> some cases, but I'm not sure of all the implications.
> 
> 2. To have special call-back functions
> 
> Those would be a set of libraries that know how to connect A -> B. So,
> you could generate your IR and flag that module as "C++" (A = C++),
> and the back-end would try to lower to x86 (B = x86) and pull the
> library/sub-function LowerAtoBPCS(). For that, you just need the
> original language annotated somehow (global metadata, magic global
> variables, add it to the triple, etc), since the back-end already fill
> the latter part.
> 
> 
> Another alternative, for you, would be to have multiple copies of NaCl
> objects (compiled with nacl-gcc) and being able to dynamically select
> at runtime, which one you're going to link against. If both nacl-gcc
> and clang follow the same PCS, that should just work.
> 
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- Sent from my brain