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

[Richard Sandiford]

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