[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