Re: i370 patches against egcs-1.1.2

[Richard Henderson <rth at cygnus dot com>]

On Fri, May 14, 1999 at 02:30:44AM -0500, linas@linas.org wrote:
> > Yes, by writing the same sort of text that would appear in the
> > ChangeLog.
> 
> Where do I put this? 

Before the patch in the mail.  See the bulk of the egcs-patches list.

> > See the output_cbranch patterns in pa.md for examples of how you
> > might emit different code depending on the distance to the target.
> 
> Too late. I've just finished this branch & base-reg optimization that 
> should be a major boost to performance.  Once you planted the idea,
> the rest was easy.  And since I had to write, not just read code
> that used XEXP & etc. I'm of course feeling like a macho programmer.
> 
> Short description: I used [(set_attr "length")] to set a max size for  
> each insn, used the resulting insn addresses to determine if a branch
> is on or off-page.  Did this by looping over all insn's looking
> for all CODE_LABEL's and all JUMP_INSN's; matched them up & voila.
> Even got the ADDR_VEC_ELT in a tablejump all working.

Sorry to rain on your parade, but unless you can defend the decision
not to use the existing branch shortening code, your new stuff won't 
go in.  Such is how maintanence problems are created.

Questions about using it, or problems encountered using it, those
we can deal with.  

> I'll need to experiment with this a bit.  One dummy question, though: 
> If I have N non-fixed regs, and an insn that needs to use N regs,
> shouldn't the global reg alloc/reload just spill evrything, and continue 
> on w/o error?

Theoretically.

>   Such a sitution could arise with inline asm's...

And does.  If you're lucky we abort.  Actually, we've gotten much
better about that since Bernd implemented local spilling.  Something
you'd have to move to egcs 1.2 to see.



r~