Re: [tree-ssa] where to fix this?

[Dale Johannesen <dalej at apple dot com>]

On Dec 22, 2003, at 3:32 PM, law@redhat.com wrote:
> In message <510D269F-324E-11D8-BBD2-000A95D7CD40@apple.com>, Dale 
> Johannesen wr
> ites:
> > On Dec 19, 2003, at 8:17 AM, law@redhat.com wrote:
> > > In message <978715DA-31C9-11D8-B11A-000A95D7CD40@apple.com>, Dale
> > > Johannesen wr
> > > ites:
> > > > I have a case where tree-ssa is calling fold() on this:
> > > >
> > > > <plus_expr 0x9c80a0
> > > >     type <integer_type 0x40d42528 int SI
> > > >         size <integer_cst 0x8e4780 constant invariant 32>
> > > >         unit size <integer_cst 0x8e4798 constant invariant 4>...
> > > >     invariant
> > > >     arg 0 <integer_cst 0x40d40570 type <boolean_type 0x40d427f8 
> > > > _Bool>
> > > > constant invariant 1>
> > > >     arg 1 <integer_cst 0x97eed0 type <integer_type 0x40d42528 int>
> > > > constant invariant 1>>
> > > >
> > > > which gets into int_const_binop, which thinks the result is _Bool 
> > > > and
> > > > truncates it to 0.
> > > > Not what we want.  Would the preference be to fix this in fold(), or
> > > > make tree_ssa
> > > > produce trees that incorporate the C promotions?
> > > We'd need more context to know what's happening.   testcases help a
> > > lot :-)
> >
> > I'm not asking anybody to fix the bug, I will do that, I just want to
> > know what the
> > defined semantics of fold() are.  Is is supposed to handle the tree
> > above or not?
> And you're running into one of the fundamental issues -- there is no
> well defined semantics to fold.  There's several messages from Roger,
> Jan and myself.  The long and short is fold is (IMHO) a *&@#$ disaster
> and needs a total redesign.

Thanks.  I was afraid of that (especially after nobody answered the 
question:)

Here's an example that crashes reliably on Darwin with -O3.  (As of a 
12/17 checkout,
I realize that's old but cvs is unresponsive just now.  The bug is hard 
to reproduce in
a small example, and it wouldn't surprise me if some change has hidden 
it.  The original
bug in SPEC perlbmk has been consistently there for quite a while 
though.)

char *foo(char *p, char *q) {
   int x = (p !=0) + (q != 0);
   if (x==2)  return "a"; else return 0;
}
extern char *bar(char*, char*) __attribute__((noinline));
char *bar(char *first, char *last)
{
  int y;
  if (!first)  return last;
  if (!last)   return first;
  if (*first == 'a')
    return foo(first, last);
  return 0;
}
main() {
  char *p = "a", *q = "b";
  if (p)
    if (bar(p,q))
      return 0;
  abort();
}

Interesting dump excerpts:

Optimizing statement T.1_11 = p_9 != 0B;
  Replaced 'p_9' with variable 'first_3'
  Replaced redundant expr 'first_3 != 0B' with '1'    //  this 1 is 
boolean, stored into an int

Optimizing statement iftmp.2_12 = T.1_11 + 1;     // boolean + int
  Replaced 'T.1_11' with constant '1'

Optimizing statement iftmp.2_12 = 0;            // on which fold didn't 
DTRT

So, we might make the types match at the first transformation, or at 
the second,
or in fold().  The first looks most attractive to me, any advice is 
appreciated.