[PATCH] D32460: ADT: handle special case of ARM environment for SuSE
Renato Golin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 28 02:17:10 PDT 2017
rengolin added a comment.
In https://reviews.llvm.org/D32460#740135, @majnemer wrote:
> In https://reviews.llvm.org/D32460#740134, @compnerd wrote:
>
> > Yes, the idea is that the textual IR uses the correct triple, unless it is overidden at the command line.
>
>
> Why not just handle this in clang?
IIRC, the problem here is of consistency.
The Triple usage throughout LLVM is broken wrt float ABI, but "hf" at the end of the environment "makes it work". The reason being that "gnueabihf" is the mostly tested environment, so it converged to work by accident.
The target that clang passes to LLVM is, therefore, also broken. Making Clang change from "eabi" to "eabihf" would "work", in the sense that in some cases, the correct float ABI would be selected. But it would also serialise the *wrong* triple in IR.
Again, that solution has "converged" to work, because the IR triple doesn't have to make sense (for example "thumbv7a"), so it's possible that, for all intended purposes, just changing the environment in the clang driver should be enough.
If it wasn't for the fact, of course, that we already do that with Arch/CPU names, sometimes getting it terrible wrong, and most times "fixing" it with by "accidental convergence".
I'm not against continuing this pattern, as I certainly don't have time (and health) to try and fix the clang driver for the Nth time, but I just want to make clear to all parties involved that none of that is a "solution". :)
The real solution would be to continue Daniel's Triple refactoring [1] until all fields are uniquely represented on both Clang and LLVM.
</rant>
[1] Some references:
- https://reviews.llvm.org/D10969
- http://lists.llvm.org/pipermail/llvm-dev/2015-July/087700.html
Repository:
rL LLVM
https://reviews.llvm.org/D32460
More information about the llvm-commits
mailing list