[llvm-commits] [llvm] r44825 - in /llvm/trunk: include/llvm/Target/TargetData.h lib/Target/TargetData.cpp

[Chris Lattner]

On Dec 11, 2007, at 1:25 AM, Duncan Sands wrote:

> Hi Chris,
>
>> Duncan, this patch gets llvm-gcc to build, but it still doesn't
>> answer the big question: why does TargetData contain information
>> about the host?
>
> well, it needed to go somewhere.  Any suggestions for a better place?
> Another possibility is to have a function isWrongEndian in target  
> data,
> which tells you if the target has opposite endianness to the host.

How about a static function in ExecutionEngine.cpp that takes a  
TargetData& ?

>> I don't think this is the right approach.  Also, you
>> can get the host endianness without autoconf by using something
>> simple like:
>>
>> bool islittleendian() {
>>    union {
>>      int i;
>>      char c;
>>    };
>>
>>    i = 1;
>>    return c;
>> }
>
> I have no particular opinion on this (except that it's amazing to me
> that there's no standard way to query the compiler for this in C+ 
> + :) ).

Ah, but no "well defined" code should depend on endianness. :)  Ah  
the differences in reality between standards and actual usage.

> Presumably the compiler will reduce this function to: return true;  
> (or false)
> at compile time, so there's no cost to your approach.

Right.

> I suppose that plenty
> of things that autoconf does could also be done in a special  
> function like this,
> yet they are left to autoconf - I have no idea what the criteria  
> are for doing
> something via autoconf or via a runtime test.

A lot of things can't be done that way, for example finding the path  
to an external tool, checking to see if your assembler has some  
feature (e.g. .cfi support), etc.

> Having the function inline in a
> header would have the advantage that the compiler would eliminate a  
> bunch of code
> in ExecutionEngine at runtime.  Since it seems that the autoconf  
> solution is not
> compatible with being exposed in a header, that suggests your  
> solution is the way
> to go.

Thanks!

-Chris