This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFD] MIPS/gas: Optimisation cannot be set to 0

On Sun, 11 Nov 2007, Richard Sandiford wrote:

> Right.  There's not really any point doing it for MIPS16 code.  The only
> kind of reordering you get is when GAS fills a delay slot that GCC didn't
> know how to fill, so ".set noreorder" would mean "don't make this
> function as small as you can".  That'd be a bit perverse on a target
> where size is really the only thing that matters.  (In contrast,
> GCC might have had good reasons to do what it did for non-MIPS16 code,
> especially on targets like the VR413x.)

 Obviously ".set noreorder" would make sense here only if GCC had 
scheduled the delay slot itself already.

> It would be quite hard for GCC to calculate precise (rather than
> conversatively-correct) lengths for every MIPS16 instruction.
> One of the problems is that the range of unextended PC-relative
> instructions depends on the low bits of the instruction's address,
> and GCC's length calculation code isn't yet ready for that kind of
> headache.

 Given the current situation it would probably be quite wise if GCC took 
the possibility for the jump to be swapped with the preceding instruction 
into account and adjusted DWARF-2 records accordingly.  Alternatively, as 
suggested by David Ung, the compact JRC/JALRC jumps could be used (where 
applicable and if permitted by the instruction set selected) keeping the 
size of code the same; though I can imagine a small performance penalty 
here resulting from one more pipeline stage being left unfilled between 
the jump is taken and its target executed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]