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

On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote:
> hi,
>
> i've got some more things to note. first, the issue is not related to
> x86_64 being the host machine - it also happens on i686/linux.
>
> 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.
> i wonder how other people are cross compiling for arm-linux-gnu?
> any help would be highly appreciated!

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 Oct 22, 2007, at 12:25 PM, Dietmar Ebner wrote:
> 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.
I'd rather not, but for long double it's unavoidable; there are  
several variants
for different targets.  Also, there are places in the backend where  
the intermediate
format is picked up and treated as host double, so endianness has to  
match for that.
I think this is avoidable, but you may have to change more places  
than you're expecting;
it's going to be a while before constant folding of libm calls is  
done in software,
for example.

There are targets that have non-IEEE float and double as well, but  
LLVM doesn't
currently support any of them.

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.
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev