[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