Hi Dave,>> The frontends (llvm-gcc, clang) appear to do the argument munging >> themselves in order to compensate. > > Yep. There are lots of corner cases that the frontend MUST handle > because LLVM does not have the necessary infrastructure.I think it's more like: because LLVM doesn't have the necessary information. Due to LLVM using structural equivalence, all kinds of types that are different in the original language end up being the same type in LLVM. Chris once explained to me, IIRC, that the ABI is defined in terms of the original language types, and unfortunately some ABI's require different handling for types that are structurally equivalent. In short, it's not always possible to know how a LLVM type should be passed, because you don't know which of several possible front-end types it came from. So you would either have to annotate the IR with all kinds of front-end type information, or require front-ends to do the ABI conformance stuff. The current solution is the latter. See PR4246 for a plan to have generic helper codes for ABI lowering. Ciao, Duncan.> >> Any plans or suggestions for implementing this properly in the backend? > > I don't think anyone has signed up to do the work. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Duncan Sands <baldrick at free.fr> writes:>> Yep. There are lots of corner cases that the frontend MUST handle >> because LLVM does not have the necessary infrastructure. > > I think it's more like: because LLVM doesn't have the necessary information.True.> Due to LLVM using structural equivalence, all kinds of types that are > different in the original language end up being the same type in LLVM. > Chris once explained to me, IIRC, that the ABI is defined in terms of > the original language types, and unfortunately some ABI's require > different handling for types that are structurally equivalent.Just so I understand this better, for which ABIs is this the case? It's not for x86_64. ARM, perhaps?> See PR4246 for a plan to have generic helper codes for ABI lowering.It seems a bit complicated to me. Wouldn't it be simpler to just encode the language type information in metadata, or, if metadata isn't appropriate because it can be dropped, in some language information piece within Type? Then the target ABI stuff can know exactly what to do and we won't have various other pieces all trying to figure out the same stuff. -Dave
On Fri, Jun 10, 2011 at 10:29 AM, David A. Greene <greened at obbligato.org> wrote:> Duncan Sands <baldrick at free.fr> writes: > >>> Yep. There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary information. > > True. > >> Due to LLVM using structural equivalence, all kinds of types that are >> different in the original language end up being the same type in LLVM. >> Chris once explained to me, IIRC, that the ABI is defined in terms of >> the original language types, and unfortunately some ABI's require >> different handling for types that are structurally equivalent. > > Just so I understand this better, for which ABIs is this the case? It's > not for x86_64. ARM, perhaps?Take, for example, _Complex long double on x86-64. Or unions on x86-64. :) -Eli>> See PR4246 for a plan to have generic helper codes for ABI lowering. > > It seems a bit complicated to me. Wouldn't it be simpler to just encode > the language type information in metadata, or, if metadata isn't > appropriate because it can be dropped, in some language information > piece within Type? Then the target ABI stuff can know exactly what to > do and we won't have various other pieces all trying to figure out the > same stuff. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On 06/10/2011 07:29 PM, David A. Greene wrote:> Duncan Sands<baldrick at free.fr> writes: >> See PR4246 for a plan to have generic helper codes for ABI lowering. > > It seems a bit complicated to me. Wouldn't it be simpler to just encode > the language type information in metadata, or, if metadata isn't > appropriate because it can be dropped, in some language information > piece within Type? Then the target ABI stuff can know exactly what to > do and we won't have various other pieces all trying to figure out the > same stuff.There's a similar problem I've been grappling with in the Pure compiler. Pure can load LLVM bitcode files (and even produce them on the fly, using clang or llvm-gcc, if you inline C/C++/Fortran code in Pure scripts) and make the functions in those files callable from Pure without having to explicitly declare the call interfaces. This is very convenient and works reasonably well, except that the bitcode loader can't distinguish between void* and char* which both end up as i8* in bitcode. (This needs to be done so that Pure strings can be properly marshalled to C and back.) To solve this, it would be *very* nice to have some kind of annotation in the bitcode which tells me whether an i8* is actually void* or char* on the C side (this would then have to be generated by the C/C++ frontend). The only way to get that kind of information that I currently see is to somehow make clang also spit out the AST along with the bitcode, but that seems wasteful. (If anyone has a better idea, please let me know.) So this kind of type annotation would be useful for more than ABI lowering, and I'd really welcome that addition. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
David A. Greene wrote:> Duncan Sands<baldrick at free.fr> writes: > >>> Yep. There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary information. > > True. > >> Due to LLVM using structural equivalence, all kinds of types that are >> different in the original language end up being the same type in LLVM. >> Chris once explained to me, IIRC, that the ABI is defined in terms of >> the original language types, and unfortunately some ABI's require >> different handling for types that are structurally equivalent. > > Just so I understand this better, for which ABIs is this the case? It's > not for x86_64. ARM, perhaps? > >> See PR4246 for a plan to have generic helper codes for ABI lowering. > > It seems a bit complicated to me. Wouldn't it be simpler to just encode > the language type information in metadata, or, if metadata isn't > appropriate because it can be dropped, in some language information > piece within Type? Then the target ABI stuff can know exactly what to > do and we won't have various other pieces all trying to figure out the > same stuff.Why should the backends know about the frontend language? It seems sensible to me that if I create a new language and a new ABI for my language then I can expect to need to teach the backend about my new ABI. We already have the default ABI for a target and the per-function calling conventions. Let's assume that neither of those are good choices for solving my problem because the ABI matches the default with only a few special cases. We could add ABI notes to the llvm::Function which specify that parameter 3 is an arm-abi-name "foo-style-passing", and the ARM backend would have to be taught how to handle that. (It would also be nice if TargetData could tell you whether a given ABI note applies to your current target.) What's nice about this is that separates the concerns of lowering the IR and the workings of the ABI. What's not so hot is that now we'll have to standardize these notes in LangRef. That's orthogonal to the concern of PR4246 which talks about providing a generic layer for lowering from the C type system to the ABI. Does this sound like a sensible start? Nick