search for: getendianness

...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, mak...

>> 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

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because

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