New x86 backend and my regstack changes...

[Richard Henderson]

On Thu, Jul 01, 1999 at 05:57:07PM +0200, Jan Hubicka wrote:
> Also I've discovered, that new backends works much better now that it
> worked last time I've tested it, so I've started to play with it. I've
> updated my two patches accepted to old backend (for changing non pairable
> negs to xors)

I've applied these bits.  Note that to use reg_dead_p, the resource
code must be active.  Which means using define_peephole2 rather than 
define_split.

>               and to avoid nonpairable forms of test instructions.

I have questions about this one.

> WIth "new backend coding style" I was able to make them better than
> originals, so hope you will like this changes. Are you interested in
> updated versions of my other i386.* patches as well?

Yes, but as independant (or at least sequential) patches, instead
of mixing up several in one patch.

> I've also found few small bugs that I've fixed (incorrect predicates
> causing compiler to crash, one forgotten tab and few others)

Applied as well.  The first attachment is the result.

> I've changed the fp operations schedulings according the docs I have and
> verified they by benchmarks, that they are correct (the fp operations really
> takes 3 cycles instead of two and FADD+FMUL can be in the pipeline
> simultaenously.  A loop of FMULS and FMUL+FADD+FADD takes same time, so
> FMUL really don't block whole pipe for two cycles.

Ok.

> I've did some deeper changes to integer instruction scheduling. I've
> implemented the immediate/displacement rule and showed to scheduler
> that read/modify and read/modify/write instructions are longer.  Also
> I've changed the ix86_reorder function to attempt pair instruction
> with same lengths. This helps, because pentium always waits for next
> instruciton to go in before both instructions finishes.
> This helps gcc to beat Intel compiler on my tests and makes me more happy :)

Cool.  I'll be applying this one shortly as well.

> I was just unable to stop myself from playing with such nice new toy.

Hehe.

>   (define_insn "testsi_1"
>     [(set (reg:CCNO 17)
> ! 	(compare:CCNO (and:SI (match_operand:SI 0 "nonimmediate_operand" "%a,rm")
> ! 			      (match_operand:SI 1 "general_operand" "in,rin"))
>   		      (const_int 0)))]

My question here is whether we should be preferencing ax as you are.
Do you get better (or smaller, for some reasonably large source) code
if you use "%*a,rm" instead?

Also, I didn't like the change from memory_address_length to 
memory_address_info.  A significantly better solution is to
commonize _all_ of the address identification code.  This I
present in the second patch.


r~