ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: $ llc -march arm -mtriple armv7-none-linux ... ParseARMTriple() will see TT == "arm-none-linux" instead of "armv7-none-linux". As a result, the target features will be set generically. (Note that using "-march armv7" is not valid.) This is clearly wrong, but I'm not clear on where/how this should be fixed. Does the -march substitution need to happen at all? Could it be disabled only for ARM? Should TargetTriple or -march be made more precise? Thanks, - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120302/ca064760/attachment.html>
On Mar 2, 2012, at 12:04 AM, David Meyer <pdox at google.com> wrote:> ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) > > In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: > > $ llc -march arm -mtriple armv7-none-linux ... > > ParseARMTriple() will see TT == "arm-none-linux" instead of "armv7-none-linux". As a result, the target features will be set generically. (Note that using "-march armv7" is not valid.) > > This is clearly wrong, but I'm not clear on where/how this should be fixed. Does the -march substitution need to happen at all? Could it be disabled only for ARM? Should TargetTriple or -march be made more precise? >When using a triple, -march doesn't add any additional information. The idea is that -march is a shorthand for a generic triple (e.g., -march=arm implies -mtriple=arm-unknown-unknown or something similar). It seems to me that using both on the llc command line should issue a diagnostic. -Jim> Thanks, > - pdox > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Jim,
There's a comment in llc.cpp:
// Allocate target machine. First, check whether the user has explicitly
// specified an architecture to compile for. If so we have to look it up
by
// name, because it might be a backend that has no mapping to a target
triple.
const Target *TheTarget = 0;
if (!MArch.empty()) {
It explicitly uses MArch over the triple for the Target lookup.
Daniel, it looks like you wrote this comment. Could you explain what you
mean by a backend with no mapping to a target triple?
Thanks,
- pdox
On Fri, Mar 2, 2012 at 9:11 AM, Jim Grosbach <grosbach at apple.com>
wrote:
>
> On Mar 2, 2012, at 12:04 AM, David Meyer <pdox at google.com> wrote:
>
> > ARM subtarget features are determined by parsing the target tuple
string
> TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp)
> >
> > In llc, the -march setting overrides the architecture specified in
> -mtriple. So when you invoke:
> >
> > $ llc -march arm -mtriple armv7-none-linux ...
> >
> > ParseARMTriple() will see TT == "arm-none-linux" instead of
> "armv7-none-linux". As a result, the target features will be set
> generically. (Note that using "-march armv7" is not valid.)
> >
> > This is clearly wrong, but I'm not clear on where/how this should
be
> fixed. Does the -march substitution need to happen at all? Could it be
> disabled only for ARM? Should TargetTriple or -march be made more precise?
> >
>
> When using a triple, -march doesn't add any additional information. The
> idea is that -march is a shorthand for a generic triple (e.g., -march=arm
> implies -mtriple=arm-unknown-unknown or something similar).
>
> It seems to me that using both on the llc command line should issue a
> diagnostic.
>
> -Jim
>
> > Thanks,
> > - pdox
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120303/b64054a5/attachment.html>