[cfe-dev] portable sizeof

David Chisnall theraven at sucs.org
Fri Oct 30 11:13:50 PDT 2009


On 30 Oct 2009, at 17:47, Jochen Wilhelmy wrote:

> this way c-code containing a sizeof could be compiled to llvm bytecode
> while the target platfrom is still mostly unknown (at least size_t has
> to be known
> and influences whether i16, i32 or i64 is used)


Platform-specific behaviour comes a long time before then.  Any #ifdef  
statements depending on architecture-specific built-in defines, for  
example, will be evaluated in the preprocessor.  For example, the  
definition of the C99 standard intptr_t type depends on this.

Preprocessed C is intrinsically not portable.  If you want to make  
clang emit portable IR from C then you will need to modify the IR  
significantly to be able to incorporate compile-time conditionals and  
a few other things.

The IR generated by clang even contains things like details of the  
calling convention used for passing and returning by-value structures,  
because LLVM doesn't hide this detail from front ends adequately.

You can, sometimes, if you're careful, write C code that can be  
compiled to platform-independent LLVM IR, but you should not expect to  
be able to do so in the general case.

I'm not sure why you think that it is more portable:

store i32 ptrtoint (struct.Foo* getelementptr inbounds (%struct.Foo*  
null, i32 1) to i32), i32* %tmp1

By this point, the types are already defined.  The struct.Foo type has  
already been defined and so this is a constant expression just as much  
as 16 is.  You could rewrite the IR so that struct.Foo was different  
(this is nontrivial, because a huge number of things in the IR will  
depend on the types), but if you want to do that then you would be  
better off just embedding a metadata node indicating that the constant  
16 is the size of struct.Foo.  Actually, if you want some portable  
serialisation of the program, the unpreprocessed C code is a much  
better choice than the LLVM IR...

David

-- Sent from my Difference Engine






More information about the cfe-dev mailing list