This is the mail archive of the gcc-patches@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: Genrecog bugfix version 2


> On Sun, Jul 25, 1999 at 03:12:25AM +0200, Jan Hubicka wrote:
> > +        /* Try to find corresponding position in the second.  */
> > +        if (cmp < 0)
> > + 	 {
> > + 	    if (d1->success.first == 0)
> > + 	      return 0;
> > + 
> > +             for (p1 = d1->success.first; p1; p1 = p1->next)
> > + 	      if (! not_both_true (p1, d2, 0))
> > + 	        return 0;
> 
> I've finally sat down and looked at this in detail.
> 
> It's incorrect.  The `success' data bear no relation to `position'.  The
> success data is all the things to try _after_ success with a given node. 
> So it's all the stuff that _doesn't_ appear in `position'.
Really? If I understand it right, the genrecog builds the tree of insn patterns.
So when possition is "aba" it denotes XEXP(XEXP(XEXP(original position),0),1),0)
(with some simplificaiton that is not important for me)
and all parts of insn with alphabetically lower strings are already tested to match.
The success.first and so on determines the branches in tree to try after. So for example
patterns are:
(unary (binary (param 1) (param 2))
(unary (binary (param 1) (unary2 (param 2)))
the unary code, binary code and param 1 are already tested.
The success.first will point to param2 test of patern 0
and next will be linked unary2 test in pattern 1 because we are
exactly on the position where branches divide.

The success.first and so on so points to tests with later position in the rtx and thus
alphabetically higher possition strings.
So with my of testing I will later or sooner reach same position in strings because I always
move in the later (if same positions exists) and there is right place to prove that insns
are disjunct.
> 
> The link I think you wanted, back up the chain, doesn't exist.  I can't
I don't want to go back. I just want to skip tests that are "out of sync"
IE tests that are for possitions in insn patterns that don't exist in both patterns.
> lay my finger on exactly what's going wrong with your example, but this
> isn't the solution. 
Sad.
> 
> Probably you should put together a minimal test for the problem.  It's
> not as simple as two patterns -- I tried that.
It is pretty simple. You may find it in my fmul patch for the backend.
But I believe the most trivial example is:
pattern0: (set:HI (subreg:HI (match_operand:SI 0 "register_operand") 0) (subreg:HI (match_operand:SI 1 "register_operand") 0))
pattern1: (set:HI (match_operand:HI 0 "register_operand") (match_operand:HI 1 "register_operand"))
Will be proved as disjunct
(as place of subreg:HI will be tested with match_operand:HI, this is ok, but second subreg;HI will be compared
with first match_operand:SI (and proved to be disjunct), because trees will get out of sync.
My patch does the trick by comparing strings of the second subreg "b" and the match_operand:SI "aa"
and skipping tests in the second until string "b" is reached (so it walks to match_operand:HI)

But probably my understanding is wrong. I currently don't have acces to gcc sources to try
more, but I will do so in next week.

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]