[cfe-dev] preserving type signatures

[David Chisnall]

On 24 Mar 2010, at 20:31, Renato Golin wrote:

> It might make sense for some platforms (such as x86_64) but it doesn't
> for all platforms, especially non-64bit ones.
> 
> I read the thread with your detailed explanations and I understand now
> why it was done and also agree that it's quite ugly. Though, maybe
> some metadata (instead of the whole C type system) could be passed
> down to the codegen to avoid this.
> 
> It's "ok" to assume most people will be using intel with GCC 64 these
> days, but IMHO, forcing (all?) other target codegens to work around a
> specific x86_64 ABI is just wrong.


You seem to be under the impression that this happens for all targets.  It does not.  If you compile your example code for FreeBSD x86, it returns the values as an i64.  If you compile for Linux x86, the return type of the function is void and there is a sret pointer passed as the first argument.

This is because, unfortunately, LLVM does not handle any of the ABI-specific calling convention logic for you.  It maps IR types to specific calling conventions (in an undocumented way, which is fun if you're writing a compiler that requires ABI compatibility with C).  

There is no assumption that 'most people will be using Intel with GCC 64' there is an assumption that, if you are using x86-64 then you want code that uses the same ABI as your system compiler.  Clang generates LLVM IR that LLVM will translate into something that has the correct ABI.

As Daniel says, you are free to define a new ABI that has your own mappings if you want more of the information preserved, but you'll still find things that LLVM IR can't represent, such as unions or the difference between complex types and structures.  If C type information is important to you then you would be better off using a representation that contains this information.  

David

-- Sent from my IBM 1620