llvm dev - Oct 2007 - [LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)

Dale Johannesen wrote:
> On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote:
>> next, i think (one of) the problem(s) is the use of
>> [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in
>> llvm-convert.cpp (see patch below).
>>
>> this fixes single precision floating point but breaks double  
>> precision.
>> for arm-softfloat-linux-gnu, FLOAT_WORDS_BIG_ENDIAN is true while
>> WORDS_BIG_ENDIAN is false. as far as i've seen, there's only a
single
>> flag for endianess in the llvm target description string, so i
don't
>> really understand how this is supposed to work.
> 
> Agree.  I think those two match on all the targets I've tried.
> 
> I think the right approach is to use REAL_VALUE_TO_TARGET_SINGLE for  
> float
> and REAL_VALUE_TO_TARGET_DOUBLE for double, then the two endiannesses
> can be handled separately.
just to be sure: we don't want to generate target dependent constants in 
the frontend, do we? this would make it imho unnecessarily  hard to deal 
with them in the backend.

what we're trying to do is to add another flag to the target machine 
that encodes the floating point endianes (just like "e" vs.
"E") and use
  it when appropriate in the backend to get the target layout 
right(e.g.,  when emitting constants and during target lowering). we'll 
test and post a corresponding patch tomorrow.

anyway, i'm obviously not the first person trying to compile for 
arm-linux and i wonder how other people achieve this, e.g., how are the 
arm-softfloat targets in the nightly tester configured?

i've changed the subject of the thread since the old one was meanwhile 
slightly misleading.

cheers and thanks again for your help,

-
dietmar

On Mon, 22 Oct 2007, Dale Johannesen wrote:
> In principle I think keeping IEEE float and double in an endian- 
> independent form in the IR files is a good idea.  BUT: I'm told 
> retaining the ability to use files in the existing format is a 
> requirement (so floats still need to occupy 8 bytes).  Since ARM target 
> doesn't currently work that one is a reasonable exception IMO, but 
> changing the format for x86, for example, would not be greeted with joy.
Yep this is a good way of putting it.  Also, if you want to *add* a target 
data specifier to capture FP endianness (in the target memory, not in the 
IR files) that would be just fine,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/