Dale Johannesen
2007-Oct-22 17:03 UTC
[LLVMdev] 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!
Dietmar Ebner
2007-Oct-22 19:25 UTC
[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
Dale Johannesen
2007-Oct-22 20:12 UTC
[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 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
Reasonably Related Threads
- [LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
- [LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
- [LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
- [LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
- [LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64