[PATCH] D21467: [llc+llvm-mc] Prefer applying -mabi to the triple where possible and allow Mips to take ABI information in the triple.

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 14:32:26 PDT 2016


Agreed, I'm not a fan of this. We have or should have sufficient API
surface to be able to parse command line options and specify things down.

-eric

On Tue, Jun 21, 2016 at 8:03 AM Rafael EspĂ­ndola <rafael.espindola at gmail.com>
wrote:

> I am mildly uncomfortable extending the triples.
>
> Would you mind sending an email to llvmdev saying why you want to do
> it and why it is better than propagating the ABI to whatever decides
> to use the integrated assembler or not?
>
> Thanks,
> Rafael
>
>
> On 21 June 2016 at 10:56, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> >> Are the new triples something we are inventing or are they supported
> already by some tool.
> >
> > A bit of both. Most of them are inventions for the LLVM internals.
> However, 'gnuabin32' and 'gnuabi64' are chosen to coincide with Debian's
> multiarch tuples (https://wiki.debian.org/Multiarch/Tuples, search for
> 'mips-linux-gnu' to find the mips examples) and will be used by the N32
> port of Debian (if/when we do it) and is used by the new N64 port of Debian.
> >
> > These triples are internal to LLVM and I'm expecting them to be (almost)
> invisible to the end user. Clang users will still use whatever triple and
> options they use today. Existing API users, existing LLVM-IR, lldb, llc,
> llvm-mc, etc. can also stick to their current triples if they wish but they
> won't be able to target N32 (which is the same position they're in at the
> moment). The reason I say 'almost' invisible is because the triples will
> show up in the 'target triple' statement of newly generated LLVM-IR. I also
> plan to have them appear in the output of 'clang --version' so that we can
> easily find out what the target for a given set of options is.
> >
> >> For example, can binutils be configured to target mips64-linux-gnuabi64?
> >
> > On Debian, yes and it selects the appropriate behaviour to target the
> N64 port of Debian. Elsewhere, yes (because of a wildcard match
> 'linux-gnu*') and anything special about it compared to mips64-linux-gnu is
> specified in options to ./configure.
> >
> >> -----Original Message-----
> >> From: Rafael EspĂ­ndola [mailto:rafael.espindola at gmail.com]
> >> Sent: 20 June 2016 14:11
> >> To: reviews+D21467+public+827b718e7f297099 at reviews.llvm.org; Daniel
> >> Sanders
> >> Cc: llvm-commits
> >> Subject: Re: [PATCH] D21467: [llc+llvm-mc] Prefer applying -mabi to the
> triple
> >> where possible and allow Mips to take ABI information in the triple.
> >>
> >> Are the new triples something we are inventing or are they supported
> >> already by some tool. For example, can binutils be configured to
> >> target mips64-linuxgnuabi64?
> >>
> >>
> >> Cheers,
> >> Rafael
> >>
> >>
> >> On 17 June 2016 at 09:25, Daniel Sanders via llvm-commits
> >> <llvm-commits at lists.llvm.org> wrote:
> >> > dsanders updated this revision to Diff 61090.
> >> > dsanders added a comment.
> >> >
> >> > Fixed a small rebase mistake that only became clear when a follow-up
> >> patch was applied
> >> >
> >> >
> >> > http://reviews.llvm.org/D21467
> >> >
> >> > Files:
> >> >   include/llvm/ADT/Triple.h
> >> >   lib/Support/Triple.cpp
> >> >   lib/Target/Mips/MCTargetDesc/MipsABIInfo.cpp
> >> >   test/CodeGen/Mips/fp16-promote.ll
> >> >   test/MC/Mips/cpsetup.s
> >> >   test/MC/Mips/elf_reginfo.s
> >> >   test/MC/Mips/mips64-register-names-o32.s
> >> >   tools/llc/llc.cpp
> >> >   tools/llvm-mc/llvm-mc.cpp
> >> >   unittests/ADT/TripleTest.cpp
> >> >
> >> >
> >> > _______________________________________________
> >> > llvm-commits mailing list
> >> > llvm-commits at lists.llvm.org
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/ecc7b11d/attachment-0001.html>


More information about the llvm-commits mailing list