https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82808
--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> ipa_get_jf_pass_through_result has multiple issues:
>
> static tree
> ipa_get_jf_pass_through_result (struct ipa_jump_func *jfunc, tree input)
> {
> tree restype, res;
>
> if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
> return input;
>
> we may miss a truncation here (and should check for CONVERT_EXPR_CODE_P).
I admit this is confusing but no. Until gcc7 we had two kinds of
pass-through jump functions, binary and really_no_operation_at_all.
NOP_EXPR was used to mark that more simple case and still is.
However, despite having unary pass-through jump functions now, we
never construct those with if the operation would be a
CONVERT_EXPR_CODE_P. Maybe we should use ERROR_MARK or something
instead of NOP_EXPR.
>
> if (!is_gimple_ip_invariant (input))
> return NULL_TREE;
>
> if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> == tcc_unary)
> res = fold_unary (ipa_get_jf_pass_through_operation (jfunc),
> TREE_TYPE (input), input);
>
> the bug here is that the operation is type-changing but we use the
> type of the input(!) rather than the type of the output when computing
> the result. I suppose the output is the type of the current formal
> parameter -- is that available somehow?
The output in the original IL was the actual argument, at IPA level we
generally assume that it is compatible with the callee formal
argument. That type is now available from the new parameter that
Prathamesh is adding with his patch, but he does not pass them from
all callers. If the type is required for more than a bunch of
not-likely-important operations, we should try harder and provide it
from everywhere (possibly incrementally).
>
> else
> {
> if (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation (jfunc))
> == tcc_comparison)
> restype = boolean_type_node;
> else
> restype = TREE_TYPE (input);
>
> same issue for operations like widen_sum_expr but of course less likely
> to hit us here.
>
> res = fold_binary (ipa_get_jf_pass_through_operation (jfunc), restype,
> input, ipa_get_jf_pass_through_operand (jfunc));
> }
> if (res && !is_gimple_ip_invariant (res))
> return NULL_TREE;
>
>
> I think the immediate thing to do is make the list of handled expression
> codes explicit - thus change the tree-code-class checks to
>
> switch (code)
> {
> case handled-unary:
> fold_unary...
>
> case handled-comparison:
> ...
>
> etc.
>
> or somehow properly get the jf "target" type.
Nowadays it should be possible to do the latter (but people always
frown when I introduce more type handling to WPA, so I would not
necessarily object to the former either).
