Subject: Re: EGCS enabled on mips
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: current-users
Date: 10/31/1998 12:06:17
Jason thorpe writes:
>On Sat, 31 Oct 1998 04:51:33 -0800 
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

> > For the addresses that the mips can handle (16-bit signed constant)
> > plus a register), breaking up addresses and doing CSE will result in
> > strictly worse code than just backing out the changes to expr.c which
> > caused the problem; but that would hurt other ports.

>How about some symbol for the config header that effectively disables
>the change to expr.c... and then define that in the MIPS config headers.

>Wouldn't that be better?

not necessarily. you never ever want to split expressions that really
work as immediate offests to a ld or store, since those are free.  but
if egcs always folds those back after splitting, everything will Just
Work.

At least for simple test cases where there really is is no opportunity
for CSE, egcs DTRT and folds the constant back into an address.

I havent looked to see if egcs re-folds "common subexpressions" back
into immediate offsets whenever it can.  the costs in the backend
movqi_internal* templates (which should control this) look wrong to
me.  (a load with a constant too big for an ori with $0 takes 2 cycles
to load, 1 more to add to the base register, and 1 more for the memory
ref: the template says it costs 2).

but if those are fixed, and egcs DTRT about when to use common
subexpressions in registers versus immediate operands, then this
should be a net win. (maybe haifa will help, if its stable on mips;
i'm building one right now).

Plus there are several comments in the source saying the IRIX
assembler/linker cant handle this trick (weird restrictions on
high-order 16-bit relocs). if so, the backend will need new templates
to handle this (via the la pseudo-insn?)

i'd go for a thre-pronged anser:
   1) a  backend macro that tells the code in expr.c that an
      expression is ``free'' and so expr.c never splits those
      in the first place;
   2) fix initialization of the mips backend variable `mips_split_addresses'
      so it gets set to 1 even for PIC code;
   3) if all else fails (mips assembler/linker?) add a template
      which uses  'la' to outpu the problem expressions.



I decided a longterm fix, thats complete for all mips ports, and
produces the best code, is too much for me right now (i dont know enuf
about irix or mips16).  ``punt''.  But I'm drafting a message to the
egcs list.