search for: nan2008

...n32 --with-fp-32=xx I create a small linux distribution from scratch using these compilers. From a sysroot layout point of view there will be folders called mips64el-linux-gnu in various places albeit the libraries in each will have wildly different ABIs. For 1) When I run gcc I get n64+softfloat+nan2008+i6400 For 2) When I run gcc I get n32+hardfloat+doublefloat+nan2008+i6400 For 1) when I run gcc -mabi=32 I get o32+soft-float+nan2008+i6400 For 2) when I run gcc -mabi=32 I get o32+hardfloat+doublefloat+nan2008+fpxx+i6400 If I want to use clang as simply as I use GCC what do I need to change in l...

...uch as Target::createTargetMachine() will always get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora). This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs NAN2008 defaults, default ABIs, etc. Other things to mention MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the ABI in the triple then we wouldn't need Triple::mips64/mips64el. From: Eric Christopher [mailto:echristo at gmail.com] Sent: 23 September 2...

...bably thinking something like "mips32r2 little endian, obviously" but this is not actually correct all the time. The true answer is 'whatever I (the person who built the toolchain) want it to mean'. It could be mips32r6, it could be mips4, it could even be big-endian mips64r5 with nan2008 and msa. It could even be octeon or p5600. In GCC toolchains, distributors routinely use configure-time options to define the triple they wish to use. Nothing is stopping anyone using the same string for completely different meanings and indeed conflicting definitions are very common. To be compati...

...uch as Target::createTargetMachine() will always get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora). This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs NAN2008 defaults, default ABIs, etc. Other things to mention MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the ABI in the triple then we wouldn't need Triple::mips64/mips64el. From: Eric Christopher [mailto:echristo at gmail.com<mailto:echristo at...

...uch as Target::createTargetMachine() will always get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora). This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs NAN2008 defaults, default ABIs, etc. Other things to mention MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the ABI in the triple then we wouldn't need Triple::mips64/mips64el. From: Eric Christopher [mailto:echristo at gmail.com<mailto:echristo at...

...uch as Target::createTargetMachine() will always get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora). This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs NAN2008 defaults, default ABIs, etc. Other things to mention MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the ABI in the triple then we wouldn't need Triple::mips64/mips64el. From: Eric Christopher [mailto:echristo at gmail.com<mailto:echristo at...

...between the parser and the target description. > > Various details (ELF headers, label prefixes, exception personality, JIT target, etc.) depend on the ABI and OS Distribution rather than just 32-bit vs 64-bit > Sure? Yep. Some OS Distributions have FPXX enabled by default. Likewise for NAN2008 (although this is currently rare). Some (will) permit mixing IEEE754-1985 and IEEE754-2008 NAN encodings (they aren't the same on Mips due to historical choices). This ends up in the ELF headers. It's related to the second class of issues discussed below. Label prefixes are normally '....

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

...uch as Target::createTargetMachine() will always get the defaults corresponding to the triple. These defaults, as we discussed above vary according to the OS (MIPS-II on Debian, MIPS32R2 on Fedora). This kind of problem also exists in other forms such as Softfloat vs Hardfloat defaults, NAN1985 vs NAN2008 defaults, default ABIs, etc. Other things to mention MIPS64 is not a fundamentally different architecture from MIPS32. If we had a representation of the ABI in the triple then we wouldn't need Triple::mips64/mips64el. From: Eric Christopher [mailto:echristo at gmail.com<mailto:echristo at...

Hi Daniel, > (from the context, you might have meant 'tuple' where you've written > 'triple'. I'm answering based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.