[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Wed Aug 10 07:58:00 GMT 2016


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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 9 Aug 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691
> 
> --- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
> Based on c#6 I started thinking about how to make tree-ssa-loop-unswitch.c
> appropriately conservative when a condition references a maybe-undefined
> SSA_NAME.
> 
> To recap, tree_may_unswitch_on has this test:
> 
>      /* Unswitching on undefined values would introduce undefined
>          behavior that the original program might never exercise.  */
>       if (ssa_undefined_value_p (use, true))
>         return NULL_TREE;
> 
> The problem is ssa_undefined_value_p returns an optimistic result -- ie, it
> will returns true iff the definition statement is empty.  So it will return
> false for an SSA_NAME that is set from a PHI node where one or more arguments
> have undefined values.

ssa_undefined_value_p returns a conservative result for the
must-be-undefined question which it is used for.  It doesn't 
conservatively answer maybe-undefined.

> ISTM this can be pretty easily fixed.
> 
> Create a bitmap and initialize it to all the SSA_NAMEs where
> ssa_undefined_value_p is true.
> 
> Examine each PHI, if the PHI has an argument on its RHS that has the bit set in
> the bitmap, then set the bit for the LHS of the PHI
> 
> Iterate on the PHIs until nothing has changed.

Simpler: in dominator order walk all PHIs and stmts, for PHIs mark
the def defined if all args are defined, for stmts mark all defs defined

no iteration necessary, no pre-seeding with ssa_undefined_value_p needed,
simply fall back to it when looking at PHI args (for parameter handling).

> [ Yes, this isn't the most efficient.  Implementation would be different to
> improve efficiency. ]
> 
> The result is the conservative set of SSA_NAMEs that may be undefined.  This
> satisfies the need of unswitching and potentially other passes that really want
> the conservative set.  

Yeah, though it computes undefinedness in the strict SSA sense.

OTOH what unswitching wants to know is whether the value is either known
to be defined or is known to be already used in the path leading from
function entry to the place we want to place the new condition.  That
can be tested with iterating over all immediate uses and a dominance
check which should improve things a bit.


More information about the Gcc-bugs mailing list