[PATCH] D21465: [llc+llvm-mc] Replace the hidden -target-abi option with a -mabi thats visible in --help.

[Daniel Sanders via llvm-commits]

> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: 17 June 2016 18:00
> To: Daniel Sanders
> Cc: reviews+D21465+public+92eb7897bc2cfded at reviews.llvm.org; llvm-
> commits; filcab+llvm.phabricator at gmail.com
> Subject: Re: [PATCH] D21465: [llc+llvm-mc] Replace the hidden -target-abi
> option with a -mabi thats visible in --help.
> 
> On 17 June 2016 at 11:22, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> >> -----Original Message-----
> >> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> >> Sent: 17 June 2016 15:16
> >> To: reviews+D21465+public+92eb7897bc2cfded at reviews.llvm.org; Daniel
> >> Sanders
> >> Cc: llvm-commits; filcab+llvm.phabricator at gmail.com
> >> Subject: Re: [PATCH] D21465: [llc+llvm-mc] Replace the hidden -target-abi
> >> option with a -mabi thats visible in --help.
> >>
> >> If it will be in the triple, why do you need the -mabi command line option?
> >
> > If LLVM's backend tests always used -triple/-mtriple to specify a complete
> triple then I
> > wouldn't need it but a lot of tests specify the architecture using -march and
> take on
> > aspects of the host triple*. The -mabi option will apply the necessary (OS
> and
> > environment dependent) transformation to the triple to achieve the
> desired ABI.
> 
> OK, we should change that if the entire information is to be available
> in the triple.

I'm not opposed to specifying the whole triple with -mtriple since it avoids the strange triples I mentioned on OSX and Windows hosts. However I should mention that doing so will cost us some test coverage unless we take measures to prevent it. For example, running 'ninja check-all' on a FreeBSD and Linux host currently covers both FreeBSD and Linux compilation whenever we don't specify the OS in the command line options. If we specified the full triple on all tests then we'd lose one of those (it would cross-compile instead) unless we add extra RUN directives to maintain it.

> So, moving the option out of MCTargetOptionsCommandFlags.h and into
> llvm-mc.cpp is a good thing, but why do you need to rename it?
> 
> Cheers,
> Rafael

I renamed it for consistency with the other target options in llc/llvm-mc such as -mcpu, and -mattr (also -march, -mtriple in llc, llvm-mc skips the leading 'm' for these two). The corresponding clang patch doesn't rename it since end-users aren't expected to call 'clang -cc1' and 'clang -cc1as' directly.