This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: changing fp insns to parallels...


> On Mon, Apr 12, 1999 at 01:06:24PM +0200, Jan Hubicka wrote:
> > So please let me know if you know about problems. I would like to start
> > actual coding quite soon.
> > The insns might look like this:
> > (parallel [
> >   (set (reg <output fp reg>) <some operation>)
> >   (use (reg %rsp))
> >   (use (const_int 0))])
> > The reg stack pass will then change last use to hold actual size of stack
> > (position of reg-stack pointer)
> > and change the middle use to (set (reg %rsp) (plus (reg %rsp) (const_int 1))
> > to generate push and -1 to generate pop.
> 
> I think this will likely cause print_operand to be more than gross.
> I'd want to see a coherent plan before I'd believe otherwise.

OK. I will look at the outputing routines today and try to figure out
what can I do...
> etc.  This representation gives print_operand everything it
> needs directly in the `indreg' pattern.  It also allows us
> to define a print_operand %<letter> (p?) to emit the pop suffix --
OK.
But for the purposes of sched and jump, it can be great if they can
get out "flat regno" of register. (like in my last proposed format).
They can then calulate dependencies correctly. Because of fstpt pointer
they will be blocked against of breaking code and maybe they can be able
to do some optimizations...

This can be done by noting fpsp value somewhere in the indreg and maybe
use flat model as I've suggested....
(so the st operands will be calculated as "REGNO-fstpt")
> 
>   (define_insn
>     [(set (match_operand:SF 0 "fpstack_or_memory_operand" "mU")
> 	  (match_operand:SF 1 "fpstack_operand" "T"))]
>     ""
>     "fst%z0%p1 %0")
> 
> where 'U' and 'T' are defined by EXTRA_CONSTRAINTS as any stacked
> register and top-of-stack respectively.
As I remembe there is problem with defining EXTRA_CONSTRAINTS, because
some of letters that belongs to this category are abused for register
classes.
> 
> The only stickler is `fucompp'.  Canonically POST_DEC doesn't
> affect any register until `after the end' of the insn.  Moreover,
> you can't normally increment the same register twice.  However,
> 
> 	(set (cc0)
> 	     (compare:CC (indreg:SF (post_dec (reg fpsp)))
> 		         (indreg:SF (plus (post_dec (reg fpsp)) 1))))
> 
> fits the rest of the patterns better than
> 
> 	(parallel [(set (cc0)
> 			(compare:CC (indreg:SF (reg fpsp))
> 				    (indreg:SF (plus (reg fpsp) 1))))
> 		   (set (reg fpsp)
> 			(plus (reg fpsp) 2))])
> 
> Since there are exactly two of these insns, I'll leave it to your
> sense of aesthetics whether you want to break this case out special
> or use the former representation and match all compares with the
> same pattern.

OK.
> 
> I warn you that this change will not make it into egcs 1.2.  It's
> up to you whether you want to dive into this now, or work on other
> smaller bits of cleanup.

I am leaving at monday and will return at first May, them I am leaving
and will return at 15th. This is after planed feature freeze I believe.
So I think the best approach is to delay this rewrite. I will have another
two weeks on mountains to think about the representation.
I think it is not good stuff for 1.2. 
I will start work on the rewrite at 15th and then wait for the release of 1.2
or forking the source tree...

Honza
> 
> 
> 
> r~

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.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.  | 
+-------------------------------------------------------------------------+


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]