[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