https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 26 Sep 2014, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
> 
> Jan Hubicka <hubicka at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |hubicka at gcc dot gnu.org
> 
> --- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Current mainline gets pretty close:
> ;; Function int f1337(obj*) (_ZL5f1337P3obj, funcdef_no=19, decl_uid=3418,
> cgraph_uid=19, symbol_order=19)
> 
> int f1337(obj*) (struct obj * obj)
> {
>   <bb 2>:
>   return 1337;
> 
> }
> 
> 
> 
> ;; Function int main() (main, funcdef_no=22, decl_uid=3427, cgraph_uid=22,
> symbol_order=22) (executed once)
> 
> Removing basic block 5
> int main() ()
> {
>   struct obj * obj;
>   int _1;
>   int _10;
> 
>   <bb 2>:
>   obj_7 = malloc (8);
>   if (obj_7 == 0B)
>     goto <bb 4>;
>   else
>     goto <bb 3>;
> 
>   <bb 3>:
>   obj_7->vtab = &vtab1337;
>   _10 = f1337 (obj_7);
>   printf ("%d\n", _10);
> 
>   <bb 4>:
>   # _1 = PHI <0(2), 1(3)>
>   return _1;
> 
> }
> 
> So we are down to one missing inline. After FRE we get:
> 
>   <bb 2>:
>   obj_13 = malloc (8);
>   if (obj_13 == 0B)
>     goto <bb 4>;
>   else
>     goto <bb 3>;
> 
>   <bb 3>:
>   obj_13->vtab = &vtab1337;
> 
>   <bb 4>:
>   # _14 = PHI <0B(2), obj_13(3)>
>   if (_14 == 0B)
>     goto <bb 6>;
>   else
>     goto <bb 5>;
> 
>   <bb 5>:
>   _4 = _14->vtab;
>   _15 = _4->f;
>   _16 = _15 (_14);
>   printf ("%d\n", _16);
> 
> 
> So purely local problem. I suppose FRE could propagate through by knowing that
> on the other path program with segfault?

Not in the way value-numbering works (it value-numbers _14 as VARYING
obviously).  The above feels like a missed jump-threading opportunity
to me.  Eventually we could also help DOM/copyprop with replacing
the test by _14 != ohj_13 ...

In my view DOM should be able to figure out a value for _14
on the else edge as well (doesn't exactly fit DOM but certainly
most easily implemented there)

Reply via email to