Message-ID:	<19990604114115.06758@atrey.karlin.mff.cuni.cz>
Date:	Fri, 4 Jun 1999 11:41:15 +0200
From:	Jan Hubicka <hubicka AT atrey DOT karlin DOT mff DOT cuni DOT cz>
To:	pgcc AT delorie DOT com
Subject:	Re: Random i386 patches.
References:	<19990602221644 DOT E324 AT cerebro DOT laendle> <19990603154857 DOT 01824 AT atrey DOT karlin DOT mff DOT cuni DOT cz> <19990603212217 DOT B15111 AT cerebro DOT laendle>
Mime-Version:	1.0
X-Mailer:	Mutt 0.84
In-Reply-To:	<19990603212217.B15111@cerebro.laendle>; from Marc Lehmann on Thu, Jun 03, 1999 at 09:22:17PM +0200
Reply-To:	pgcc AT delorie DOT com
X-Mailing-List:	pgcc AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> On Thu, Jun 03, 1999 at 03:48:57PM +0200, Jan Hubicka wrote:
> > > * your long mov patch was broken (argument mismtach in singlemove).
> > Oops... I will take a look for it and update it (at least for egcs)
> 
> The version in pgcc cvs is fixed (i.e. it inhibits the optimization in
> that case).
> 
> > > * pgcc still generates movdf mem <- const insns so movdf with
> > >   i387_register_operand does not work.
> > Huh. I don't understand what do you mean...
> 
> you inihibit constants in the movdf pattern after reload, yet these
> pattersn exist (and cause the compiler to not abort).
Well, I don't remember exactly what patch do you mean. I've made first patch
to clean up predicates (and allo extends to be combined in). In this case I didn't
touch the mov?f patterns, because they are just different. (they must allow
the integer registers operations and have separate extend patterns)
If the patch touched move pattern, this is some lossage caused by applying patch
to different md file. Only arithmetic and compare patterns needs to be changed.

Also I've made second patch to prohibit constant operands before reload, let combine
combine memory references to arithmetic instructions and then reload's CSE return
back constants whenever possible. But this is probably not the patch you was talking
about.
> 
> > > * your patch to movdf_push is broken.
> > > * and, well one patch contained HTML :(
> > Oops.. I was getting them from egcs mailing list archives and I probably
> > didn't got rid of those html tags completely...
> 
> The weird thing is that only < was escaped, whereas & was not. Shoddy list
> archive ;)
> 
> > > I also removed the subl => pushl peephole from pgcc (the 4 byte one, not
> > > the 8 byte one).
> > I've done some tests with translating sobl-> two pushes and at least on my
> > Pentium, it don't help...
> 
> How have you tested? In my (limited) tests it was slightly faster since it
> avoids possible agis when arguments are fetched.
I've implemented it in similar way as I did for one push (wrote expanders)
(the code was actually inspired by pgcc) and run our benchmark suite.
Because it caused more looss than hit, I've revert this change.
But I didn't tested it one AMD or PPro, but they ocupy more decoders and
generate more uops, so I don't this they are faster.
I was asking Richard to do this and he told that he will do it before aplying
the patch, but he didn't aplied it yet..
> 
> > > How about doing this for pops as well? ;)
> > Hmm... you need some register to pop into. Any idea where to get it?
> 
> If I had one... Maybe one could scan for REG_DEAD notes (these should be
> valid in current egcs and pgcc snapshots).
Really? I believe that jump pass messes them up (it repeats regscan).
And before jump they are messed up by sched (important is that they didn't get
to regstack, so my regstack rewrite was much oglier...
but fact is,t hat this should not be problem, because regscan analysis are
just exact enought...
Maybe we can employ same strategy as was suggested for riscify optimization.
Write special pattern for decrementing esp and let reload to put scratch
register when available...
OOPS... this is nonsence, because those patterns are generated after reload uff...
> 
> > Yesterday I've done some work, but didn't got very far. I will download
> > the patches i386 files and restart next week (I have exams now, so I am
> > quite busy)
> 
> Then I can only wish you good luck! Ah, you're so good as not to depend on
> luck anyway... ;)
Uhh :)
I am not very good in exams, wspecially when I spend whole semmester by going
to trips and hacking gcc.....
> 
> > > I'll try to get out a snapshot soon, btw.
> > Cool :)
> 
> Actually, I buggered Bernhard to do it, and he seems to be already busy
> doing it ;)

Honza
> 
> --  
>       -----==-                                             |
>       ----==-- _                                           |
>       ---==---(_)__  __ ____  __       Marc Lehmann      +--
>       --==---/ / _ \/ // /\ \/ /       pcg AT goof DOT com      |e|
>       -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
>     The choice of a GNU generation                       |
>                                                          |

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka AT freesoft DOT cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/, games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+

- Raw text -