This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New x86 backend and my regstack changes...
- To: Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>
- Subject: Re: New x86 backend and my regstack changes...
- From: Richard Henderson <rth at cygnus dot com>
- Date: Thu, 1 Jul 1999 17:27:14 -0700
- Cc: egcs-patches at egcs dot cygnus dot com
- References: <19990622163925.51408@atrey.karlin.mff.cuni.cz> <19990622095546.B1012@cygnus.com> <19990624170020.62399@atrey.karlin.mff.cuni.cz> <19990624105721.C21778@cygnus.com> <19990625152610.53046@atrey.karlin.mff.cuni.cz> <19990625113107.B23285@cygnus.com> <19990701175707.31713@atrey.karlin.mff.cuni.cz>
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~
y1.gz
y2.gz