search for: getendian

...n target endianness. Here's a sketch of how it would work: 1. Extend TargetData::isBigEndian() and LLVM bitcode's "target data layout string" so that endianness is represented as either big, little or unknown. (I see there's already support for something like this in Module::getEndianness().) 2. For optimisations (like parts of SRA) that depend on knowing the target endianness, restrict or disable them as necessary if the target endianness is unknown. I think this will only affect a small handful of optimisations. 3. In llvm-gcc, if the LLVM backend reports unknown endianness,...

>> I'm already working on this myself. Would you be interested in having >> this work contributed back to LLVM? > > If this were to better support target independent languages, it would > be very useful. If you're just trying to *reduce* the endianness > assumptions that leak through, I don't think it's a good approach. > There is just no way to solve

...the thread) As far as this section is concerned, I don't intend to change the MC API or the TargetMachine API at all except in so far as replacing Triple objects with a TargetTuple. It's the Triple/TargetTuple API that changes to provide more convenient setters and getters like setEndian()/getEndian(). As you can see the API side is uninteresting. The important bit is that the values inside the TargetTuple reflect the desired target and not the arbitrary triple string. The ABI follow-on work is slightly different but not very much so. As above, I don't intend to change the MC/TargetMachin...

I think we need to take a step further back and re-enter from the right starting point. The thing that's bothering me about the push back so far is that it's trying to discuss and understand the consequences of resolving the core problem while seemingly ignoring the core problem itself. The reason I've been steering everything back to GNU Triple's being ambiguous and inconsistent