[patch] Fix PHI optimization issue with boolean types

Eric Botcazou ebotcazou@adacore.com
Mon Oct 24 09:15:00 GMT 2016


> Btw, if int_fits_type_p is supposed to be only called for INTEGER_TYPEs
> then
> 
>       /* If arg1 is an INTEGER_CST, fold it to new type.  */
>       if (INTEGRAL_TYPE_P (TREE_TYPE (new_arg0))
>           && int_fits_type_p (arg1, TREE_TYPE (new_arg0)))
>         {
>           if (gimple_assign_cast_p (arg0_def_stmt))
>             new_arg1 = fold_convert (TREE_TYPE (new_arg0), arg1);
>           else
>             return NULL;
>         }
> 
> should maybe be changed to check for INTEGER_TYPE instead of
> INTEGRAL_TYPE_P?  And int_fits_type_p should have an assert
> asserting it is fed only INTEGER_TYPEs?

Yes, that would certainly solve the problem too.  No strong opinion, my 
proposed fix was a compromise aimed at changing nothing except for Ada.

> Alternatively int_fits_type_p looks at TYPE_MIN/MAX_VALUE, would
> it work to set that to [0, 1] for your Ada BOOLEAN_TYPEs?

No, BOOLEAN_TYPEs are base types in Ada so must have maximal range.

> For your patch, can you use integer_zerop () || integer_truep () and also
> fix wi::fits_to_tree_p?

But integer_truep is just integer_onep for BOOLEAN_TYPEs.  And fits_to_tree_p 
doesn't really need to be changed if int_fits_type_p is and the API layering 
is properly enforced, does it?

> Would it work to have wide_int_to_tree check that we never generate
> a BOOLEAN_TYPE constant that is not zero or one?  That is, does
> the Ada FE create those?

In a valid program, no.  In an invalid program, maybe, in which case we don't 
want to ICE so we would need to filter them out and raise Constraint_Error 
instead when we run into one; certainly doable I'd say.

-- 
Eric Botcazou



More information about the Gcc-patches mailing list