On Wed, 23 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 23, 2022 at 11:38:30AM +0100, Richard Biener wrote:
> > If we go for a match.pd solution I'd go with the other one but as said
> > in the PR I think we should constant fold bswap (1(OVF)) but simply
> > make the (OVF) sticky as done in other constant foldings.
>
> Changing what fold-const-call.cc does at this point seems extremely risky to
> me. There are many different builtins, shall we propagate e.g.
> TREE_OVERFLOW from INTEGER_CST operands to REAL_CST result, or vice versa,
> etc.? I think not folding those is the conservatively right answer, we
> don't have time to analyze all those dozens of different builtins and all
> their corner cases, and with OVF in there they aren't valid C or C++
> constant expressions, so we don't need to fold those during GENERIC,
> and in GIMPLE we drop the overflow flags and can fold those there then.
Note we're not 100% there on a (OVF)-free GIMPLE IL.
At this point I'd simply adjust
static tree
fold_const_call_1 (combined_fn fn, tree type, tree arg)
{
machine_mode mode = TYPE_MODE (type);
machine_mode arg_mode = TYPE_MODE (TREE_TYPE (arg));
if (integer_cst_p (arg))
{
if (SCALAR_INT_MODE_P (mode))
{
wide_int result;
if (fold_const_call_ss (&result, fn, wi::to_wide (arg),
TYPE_PRECISION (type), TREE_TYPE (arg)))
return wide_int_to_tree (type, result);
to check if (TREE_CODE (arg) == INTEGER_CST) and
return force_fit_type (type, result, 0, TREE_OVERFLOW (arg));
not constant folding something with constant arguments is much
more risky than accidentially dropping a TREE_OVERFLOW (as we can
see with this endless recursion). All cases currently handled
in the fold_const_call_ss overload do not in itself perform
arithmetic that can introduce overflow from an argument that
does not have TREE_OVERFLOW set.
Just fixing this single case leaves others unfixed, but for
example complex_cst_p fails to check for TREE_OVERFLOW already.
Richard.
