Re: RFA (gimplify): PATCH to implement C++ order of evaluation paper

[Jason Merrill <jason at redhat dot com>]

On Tue, Jun 28, 2016 at 10:00 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
>>>  gimple_predicate
>>>  rhs_predicate_for (tree lhs)
>>>  {
>>> -  if (is_gimple_reg (lhs))
>>> +  if (will_be_gimple_reg (lhs))
>>>      return is_gimple_reg_rhs_or_call;
>>>    else
>>>      return is_gimple_mem_rhs_or_call;
>>> @@ -4778,10 +4811,6 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
>>>       that is what we must do here.  */
>>>    maybe_with_size_expr (from_p);
>>>
>>> -  ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
>>> -  if (ret == GS_ERROR)
>>> -    return ret;
>>> -
>>>    /* As a special case, we have to temporarily allow for assignments
>>>       with a CALL_EXPR on the RHS.  Since in GIMPLE a function call is
>>>       a toplevel statement, when gimplifying the GENERIC expression
>>> @@ -4799,6 +4828,10 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
>>>    if (ret == GS_ERROR)
>>>      return ret;
>>>
>>> +  ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue);
>>> +  if (ret == GS_ERROR)
>>> +    return ret;
>>> +
>>>    /* In case of va_arg internal fn wrappped in a WITH_SIZE_EXPR, add the type
>>>       size as argument to the call.  */
>>>    if (TREE_CODE (*from_p) == WITH_SIZE_EXPR)
>>
>> I wonder if instead of trying to guess early what we'll gimplify into it
>> wouldn't be better to gimplify *from_p twice, first time with a predicate
>> that would assume *to_p could be gimplified into is_gimple_ref, but
>> guarantee there are no side-effects (so that those aren't evaluated
>> after lhs side-effects), and second time if needed (if *to_p didn't end up
>> being is_gimple_reg).  So something like a new predicate like:
>
> Yes, that is what I was suggesting.

How about this?  I also have a patch to handle assignment order
entirely in the front end, but my impression has been that you wanted
to make this change for other reasons as well.

In other news, I convinced the committee to drop function arguments
from the order of evaluation paper, so we don't have to worry about
that hit on PUSH_ARGS_REVERSED targets.

Jason

Attachment: gimplify-modify.diff
Description: Text document