[llvm] r200051 - [Mips] TargetStreamer ELF flag Support for default and commandline options.

[Daniel Sanders]

> -----Original Message-----
> From: Richard Sandiford [mailto:rsandifo at linux.vnet.ibm.com]
> Sent: 29 January 2014 10:57
> To: Daniel Sanders
> Cc: Rafael Espíndola; Jack Carter; llvm-commits
> Subject: Re: [llvm] r200051 - [Mips] TargetStreamer ELF flag Support for
> default and commandline options.
> 
> Daniel Sanders <Daniel.Sanders at imgtec.com> writes:
> >> -----Original Message-----
> >> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> >> Sent: 27 January 2014 16:23
> >> To: Daniel Sanders
> >> Cc: Jack Carter; llvm-commits
> >> Subject: Re: [llvm] r200051 - [Mips] TargetStreamer ELF flag Support
> >> for default and commandline options.
> >>
> >> On 27 January 2014 08:23, Daniel Sanders <Daniel.Sanders at imgtec.com>
> >> wrote:
> >> > Hi Rafael,
> >> >
> >> > To be fair to Jack, this commit was reviewed internally by myself,
> >> > Matheus
> >> Almeida, and Vladimir Medic before commit. I mention this because I
> >> don't think it's fair that Jack takes all of the criticism while we
> >> stand by and watch.
> >>
> >> While it is up to mips what internal procedures you guys use, the
> >> criticism about lack of understanding of the general design of MC
> >> stands. I would suggest that simply doing reviews in the open would
> >> be the most productive.
> >>
> >> > When I reviewed this patch, I considered it a step forwards on the
> >> > basis
> >> that ELF output by the assembler would have the correct eflags
> >> without the need for the hack directive.
> >>
> >> To restate my original email, the patch basically renamed
> >> emitMipsHackELFFlags with emitMipsELFFlags. The reason for the
> >> "MipsHack" was to clearly state that it was a hack. Created as a
> >> short term solution to get a working solution that was consistent
> >> with the MC design of one method per assembly directive. Just
> >> removing the marker would be bad, but the patch went much further: it
> >> created a completely separate and duplicated code path for the
> >> deciding which flags to use when going from a .s -> to a .o.
> >>
> >> The objective (even more important than the design by which it is
> >> achieved) of MC is that generated object files have a corresponding
> >> assembly file. That avoids us getting to the point where the .s we
> >> produce are no more than a not too reliable debug helper.
> >
> > Just to clarify part of that objective. Should the assembly file be
> > completely self-contained, or are command line arguments permitted to
> > carry the initial state? The reason I ask is that I'm not 100% certain
> > that the former is currently possible in all cases. For example, I'm
> > fairly certain there is no directive equivalent to -mmsa in gas,
> > although in this particular case we should definitely add one if it
> > doesn’t already exist.
> 
> FWIW, the -mmsa-equivalent directive is ".set msa" (with a corresponding
> ".set nomsa").  All ASEs have both a command-line option -mfoo and
> directives ".set foo"/".set nofoo".
> 
> However, with the exception of MIPS16 and microMIPS, the traditional
> behaviour is that only the command-line option sets any associated ELF flags.
> The idea is that if you pass a -mfoo option, you're saying all the code assumes
> the availability of foo, so the requirement should be recorded in the ELF
> header.  On the other hand, one of the main uses of ".set" is to switch
> temporarily to a different architecture.
> This can be used to implement dynamic selection of architecture-specific
> routines (in a similar way to IFUNCs, except IFUNCs proper aren't supported
> yet).  It's also used for things like getting the TLS base register (".set
> mips32r2" around an RDHWR, with the RDHWR being emulated where
> necessary).
> 
> Thanks,
> Richard

Thanks. I can see the support for '.set msa' in binutils now. We'll need to implement it in LLVM at some point (for the planned full assembler) but for now we can stick to the more usual -mmsa option.