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: Fri, 2 Jul 1999 10:44:43 -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> <19990701191220.A4102@cygnus.com> <19990702155840.08495@atrey.karlin.mff.cuni.cz>
On Fri, Jul 02, 1999 at 03:58:40PM +0200, Jan Hubicka wrote:
> > "two" != 4? I changed it to 2 -- if this is wrong, you'll have
> > to expand on the comment.
>
> I comment this in the mincycles variable. The cycles are counted together for
> both pipes. Because both pipes stalls two cycles, results is 2*2=4
Ok. Will you please change around the wording a bit to make that
more clear? Perhaps using "foo += 2 + 2" in the code will doubly
reinforce the idea. Constant arithmetic is free, after all. ;-)
> I think there is problem in this patch. In case two UV instructions are
> paired and they have different lenghths, sched will attempt to fill the
> pipe, once the shorter finishes and this may mess up the pairing algoritmus
> at all.
Yes, I wondered about this.
> Do you have any idea how to fix this?
> In my old MD_SCHED macros I was avoiding this by letting variable issue to
> refuse all instructions (by returning negative numbers). The MD_SCHED_REORDER
> had clock parameter that it was using to test whether pipe can accept new
> instructions or not. Do you have idea for better solution?
Not really. I think the reorder clock parameter is a pretty
reasonable solution, actually.
r~