On Wed, Sep 15, 2021 at 11:31 AM Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Wed, 15 Sept 2021 at 17:55, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I've submitted this patch[3], which turns off config.guess by default >> and tries to determine the host triple using the host compiler. Given >> all the different combinations for triples, I don't know if there is >> any better way to test this than to turn it off and wait for the bug >> reports. > > > I think this is a good change and one that we should really work on, but I'm not sure compiler front-ends are a drop-in replacement for all variations.+1 :)> Perhaps add the option and make it ON by default for now, which will still work for all current platforms, and add the possibility of turning guessing OFF and allowing those that aren't supported by out very old config.guess version to use the compiler.I think config.guess can be OFF by default. Doing two stages probably doesn't bring too much benefit. The nature of such a change is that only when I flip the default, users will actually notice. But I have some theories that switching now will actually be better.... Read on. For the patch (https://reviews.llvm.org/D109837), I suggested that we can use {gcc,clang} -dumpmachine. Users of alternative compilers have already contributed relevant logic to llvm/cmake/modules/GetHostTriple.cmake , and we should just focus on gcc/clang which are more relevant for the existing config.guess use cases. I believe {gcc,clang} -dumpmachine is correct in more cases than config.guess . When is config.guess wrong? Here are two examples that I can attest: 1. For example, I have an unfinished upgrade from FreeBSD 12.2 to FreeBSD 13.0. The host compiler's `/usr/bin/clang -dumpmachine` output remains x86_64-unknown-freebsd12.2 while config.guess starts to say x86_64-unknown-freebsd13 because it just checks `uname -a`. 2. On musl based Linux distributions, other than riscv*, all have incorrect *-linux-gnu triplets. So on Alpine Linux amd64, I need to set -DLLVM_HOST_TRIPLE=x86_64-alpine-linux-musl because config.guess says x86_64-unknown-linux-gnu, which is wrong. I think this may be wrong for *-suse-* and *-redhat-* as well but I don't have such machines at hand.> Fixing the triple in the front-end isn't really trivial, there are a number of replacements on the triple until it hits the middle-end, so this may actually create problems that aren't easy to fix down the line. > > Just like moving from automake to CMake, I think we need to do this slowly and changing buildbots until all are running the new format, then we change the default behaviour. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- 宋方睿
On Wed, Sep 15, 2021 at 12:32 PM Fāng-ruì Sòng <maskray at google.com> wrote:> > On Wed, Sep 15, 2021 at 11:31 AM Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Wed, 15 Sept 2021 at 17:55, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> > >> I've submitted this patch[3], which turns off config.guess by default > >> and tries to determine the host triple using the host compiler. Given > >> all the different combinations for triples, I don't know if there is > >> any better way to test this than to turn it off and wait for the bug > >> reports. > > > > > > I think this is a good change and one that we should really work on, but I'm not sure compiler front-ends are a drop-in replacement for all variations. > > +1 :) > > > Perhaps add the option and make it ON by default for now, which will still work for all current platforms, and add the possibility of turning guessing OFF and allowing those that aren't supported by out very old config.guess version to use the compiler. > > I think config.guess can be OFF by default. Doing two stages probably > doesn't bring too much benefit. > The nature of such a change is that only when I flip the default, > users will actually notice.s/I/we/ :) When GCC or Clang is unavailable and the compiler is not an existing with encoded logic (see MSVC, z/OS), the cmake code will give a nice warning that -DLLVM_HOST_TRIPLEshould be specified explicitly. This seems much better than config.guess potentially inferring a wrong triplet.> But I have some theories that switching now will actually be better.... Read on. > > For the patch (https://reviews.llvm.org/D109837), I suggested that we > can use {gcc,clang} -dumpmachine. > Users of alternative compilers have already contributed relevant logic > to llvm/cmake/modules/GetHostTriple.cmake , > and we should just focus on gcc/clang which are more relevant for the > existing config.guess use cases. > I believe {gcc,clang} -dumpmachine is correct in more cases than config.guess . > > When is config.guess wrong? Here are two examples that I can attest: > > 1. For example, I have an unfinished upgrade from FreeBSD 12.2 to FreeBSD 13.0. > The host compiler's `/usr/bin/clang -dumpmachine` output remains > x86_64-unknown-freebsd12.2 while config.guess starts to say > x86_64-unknown-freebsd13 because it just checks `uname -a`. > > 2. On musl based Linux distributions, other than riscv*, all have > incorrect *-linux-gnu triplets. > So on Alpine Linux amd64, I need to set > -DLLVM_HOST_TRIPLE=x86_64-alpine-linux-musl > because config.guess says x86_64-unknown-linux-gnu, which is wrong. > > I think this may be wrong for *-suse-* and *-redhat-* as well but I > don't have such machines at hand. > > > > > Fixing the triple in the front-end isn't really trivial, there are a number of replacements on the triple until it hits the middle-end, so this may actually create problems that aren't easy to fix down the line. > > > > Just like moving from automake to CMake, I think we need to do this slowly and changing buildbots until all are running the new format, then we change the default behaviour. > > > > cheers, > > --renato > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > 宋方睿-- 宋方睿
On 9/15/21 12:32 PM, Fāng-ruì Sòng wrote:> On Wed, Sep 15, 2021 at 11:31 AM Renato Golin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> On Wed, 15 Sept 2021 at 17:55, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I've submitted this patch[3], which turns off config.guess by default >>> and tries to determine the host triple using the host compiler. Given >>> all the different combinations for triples, I don't know if there is >>> any better way to test this than to turn it off and wait for the bug >>> reports. >> >> >> I think this is a good change and one that we should really work on, but I'm not sure compiler front-ends are a drop-in replacement for all variations. > > +1 :) > >> Perhaps add the option and make it ON by default for now, which will still work for all current platforms, and add the possibility of turning guessing OFF and allowing those that aren't supported by out very old config.guess version to use the compiler. > > I think config.guess can be OFF by default. Doing two stages probably > doesn't bring too much benefit. > The nature of such a change is that only when I flip the default, > users will actually notice. > But I have some theories that switching now will actually be better.... Read on. > > For the patch (https://reviews.llvm.org/D109837), I suggested that we > can use {gcc,clang} -dumpmachine. > Users of alternative compilers have already contributed relevant logic > to llvm/cmake/modules/GetHostTriple.cmake , > and we should just focus on gcc/clang which are more relevant for the > existing config.guess use cases. > I believe {gcc,clang} -dumpmachine is correct in more cases than config.guess . > > When is config.guess wrong? Here are two examples that I can attest: > > 1. For example, I have an unfinished upgrade from FreeBSD 12.2 to FreeBSD 13.0. > The host compiler's `/usr/bin/clang -dumpmachine` output remains > x86_64-unknown-freebsd12.2 while config.guess starts to say > x86_64-unknown-freebsd13 because it just checks `uname -a`. > > 2. On musl based Linux distributions, other than riscv*, all have > incorrect *-linux-gnu triplets. > So on Alpine Linux amd64, I need to set > -DLLVM_HOST_TRIPLE=x86_64-alpine-linux-musl > because config.guess says x86_64-unknown-linux-gnu, which is wrong. > > I think this may be wrong for *-suse-* and *-redhat-* as well but I > don't have such machines at hand. >config.guess is wrong on Red Hat systems (which is why I first started looking into this). -Tom> > >> Fixing the triple in the front-end isn't really trivial, there are a number of replacements on the triple until it hits the middle-end, so this may actually create problems that aren't easy to fix down the line. >> >> Just like moving from automake to CMake, I think we need to do this slowly and changing buildbots until all are running the new format, then we change the default behaviour. >> >> cheers, >> --renato >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >
On Wed, 15 Sept 2021 at 20:32, Fāng-ruì Sòng <maskray at google.com> wrote:> The nature of such a change is that only when I flip the default, > users will actually notice. >Getting a different triple may be worse than the wrong triple. The wrong triple crashes something and is easy to identify. A different, but valid, triple may bring slight architectural changes down the line that are difficult to spot. Changing the triple on the front end isn't always trivial either. There's a whole dance of changing triples in the clang driver that defies logic sometimes. The command line options to the actual front-end depend on the triple and the path taken, which in turn, can change code generation in unpredictable ways down the line. Users of alternative compilers have already contributed relevant logic> to llvm/cmake/modules/GetHostTriple.cmake , > and we should just focus on gcc/clang which are more relevant for the > existing config.guess use cases. > I believe {gcc,clang} -dumpmachine is correct in more cases than > config.guess . >Not only that, but using the compiler driver to "predict" what the compiler front-end needs is the obvious thing to do. I'm not against the change, I think we should have done this a long time ago, but I think we can give people some grace time to test out on their sides, especially downstream people and less popular platforms that still use clang/gcc to build LLVM. Giving them a CMake flag to test out for a few weeks wouldn't hurt before we turn it on by default. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210916/89b79fb8/attachment.html>