[patch] Fix PHI optimization issue with boolean types

Eric Botcazou ebotcazou@adacore.com
Fri Oct 21 07:40:00 GMT 2016


> Btw, isn't this the issue?  You'd need to avoid this as well I guess:
> 
>           /* Special case comparing booleans against a constant as we
>              know the value of OP0 on both arms of the branch.  i.e., we
>              can record an equivalence for OP0 rather than COND.
> 
>              However, don't do this if the constant isn't zero or one.
>              Such conditionals will get optimized more thoroughly during
>              the domwalk.  */
>           if ((code == EQ_EXPR || code == NE_EXPR)
>               && TREE_CODE (op0) == SSA_NAME
>               && ssa_name_has_boolean_range (op0)
>               && is_gimple_min_invariant (op1)
>               && (integer_zerop (op1) || integer_onep (op1)))
>             {
> ...
> 
> and thus:
> 
> bool
> ssa_name_has_boolean_range (tree op)
> {
>   gcc_assert (TREE_CODE (op) == SSA_NAME);
> 
>   /* Boolean types always have a range [0..1].  */
>   if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE)
>     return true;
> 
> as said, there are _very_ many places in the compiler you'd need to "fix".

I don't think so, you just need to prevent the compiler from creating boolean 
values that are not zero and one, there is none in a valid Ada program.  This 
has worked perfectly for years, it's because factor_out_conditional_conversion 
breaks the documented interface of int_fits_type_p by sending it a boolean 
type instead of an integer type that the regression was introduced.  This was 
unfortunatelty not caught in the review, so we need to do damage control now, 
including on the 6 branch, and my patch is a rather safe way of doing it.

> Basically treating BOOLEAN_TYPE this way is to cover frontends like
> fortran who have multiple boolean types of different size (and not precision
> 1 IIRC).  An alternative would be to track them all down and force their
> precision to 1 with unknown fallout.  And then document BOOLEAN_TYPE
> isn't really special anymore (and fix all places).  But then, why do we have
> BOOLEAN_TYPE ...

I think BOOLEAN_TYPE essentially works fine for Ada if you don't try to treat 
it like an INTEGER_TYPE, as the new factor_out_conditional_conversion does...

-- 
Eric Botcazou



More information about the Gcc-patches mailing list