On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law <l...@redhat.com> wrote:
> Before diving into the patch I think we should figure out why we see such
> different effects of eliminating these paths from the CFG.  Your assertion
> is eliminating them will result in more false positives and less
> optimization while my assertion is the opposite.

Warnings:

$ cat q.c
#if 0
#define UNREACHABLE() __builtin_unreachable()
#else
#define UNREACHABLE() break
#endif

typedef enum fruits { banana = 0, apple = 1, pear = 2, orange = 3 } fruit;

extern void price_fruit_of_the_day (int);

void
discount_of_the_day (fruit f)
{
  int p, c = (int) f;
  switch (f)
  {
    case banana:
      UNREACHABLE ();
    case apple:
      p = 3 * c + 4;
      break;
    case pear:
    case orange:
      p = 7;
      break;
  }
  price_fruit_of_the_day (p);
}
$ # Compiled with UNREACHABLE defined as break:
$ ./cc1 -quiet -W -Wall -Wextra q.c -fdump-tree-all -O1
q.c: In function 'discount_of_the_day':
q.c:28:26: warning: 'p' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   price_fruit_of_the_day (p);
                          ^
$ # Compiled with UNREACHABLE defined as builtin_unreachable:
$ ./cc1 -quiet -W -Wall -Wextra q.c -fdump-tree-all -O1
$


For optimizations it's a bit more difficult. The situations I'm
looking at, are all sinking related, and I suspect that most missed
optimizations will be of this form:

int foo (int b, int c, int d)
{
  int res, r = 0;
  res = 5 * d + b;
  if (d)
    __builtin_unreachable ();
  if (c)
    r = res;
  return r;
}

The "res =" statement can be sunk into the conditional arm of "if(c)"
and tree-ssa-sink.c is able to do so. But secondary effects are missed
(and test cases for this are hard to reduce to mailing list acceptable
size ;-) because tree-ssa-sink walks the post-dominator tree and, with
the right amount of bad luck, it visits the "res=" statement _before_
the part of the (forward-)dominator tree below "if(d)" because the
basic block containing "res=" has EXIT as its immediate
post-dominator, because that's where __builtin_unreachable() leads to.
The "optimistic" post-dominator of "res=" is the "if(c)" block, of
course, because the builtin_unreachable is a kind-of assert, not
something that can really ever happen.

I already showed how the control dependence graph looks Wrong with
__builtin_unreachable calls in place. Any transformation using the CDG
will also be less effective because of this.

Ciao!
Steven

Reply via email to