On 19-02-15 14:03, Richard Biener wrote:
> On Thu, 19 Feb 2015, Tom de Vries wrote:
>
>> On 19-02-15 11:29, Tom de Vries wrote:
>>> Hi,
>>>
>>> I'm posting this patch series for stage1:
>>> - 0001-Disable-lang_hooks.gimplify_expr-in-free_lang_data.patch
>>> - 0002-Add-gimple_find_sub_bbs.patch
>>> - 0003-Factor-optimize_va_list_gpr_fpr_size-out-of-pass_std.patch
>>> - 0004-Handle-internal_fn-in-operand_equal_p.patch
>>> - 0005-Postpone-expanding-va_arg-until-pass_stdarg.patch
>>>
>>> The patch series - based on Michael's initial patch - postpones expanding
>>> va_arg
>>> until pass_stdarg, which makes pass_stdarg more robust.
>>>
>>> Bootstrapped and reg-tested on x86_64 using all languages, with unix/ and
>>> unix/-m32 testing.
>>>
>>> I'll post the patches in reply to this email.
>>>
>>
>> This patch postpones expanding va_arg until pass_stdarg.
>>
>> We add a new internal function IFN_VA_ARG. During gimplification, we map
>> VA_ARG_EXPR onto a CALL_EXPR with IFN_VA_ARG, which is then gimplified in to a
>> gimple_call. At pass_stdarg, we expand the IFN_VA_ARG gimple_call into actual
>> code.
>>
>> There are a few implementation details worth mentioning:
>> - passing the type beyond gimplification is done by adding a NULL pointer-
>>    to-type to IFN_VA_ARG.
>> - there is special handling for IFN_VA_ARG that would be most suited to be
>>    placed in gimplify_va_arg_expr. However, that function lacks the scope for
>>    the special handling, so it's placed awkwardly in gimplify_modify_expr.
>> - there's special handling in case the va_arg type is variable-sized.
>>    gimplify_modify_expr adds a WITH_SIZE_EXPR to the CALL_EXPR IFN_VA_ARG for
>>    variable-sized types. However, this is gimplified into a gimple_call which
>>    does not have the possibility to wrap it's result in a WITH_SIZE_EXPR. So
>>    we're adding the size argument of the WITH_SIZE_EXPR as argument to
>>    IFN_VA_ARG, and at expansion in pass_stdarg, wrap the result of the
>>    gimplification of IFN_VA_ARG in a WITH_SIZE_EXPR, such that the subsequent
>>    gimplify_assign will generate a memcpy if necessary.
>> - when gimplifying the va_arg argument ap, it may not be addressable. So
>>    gimplification will generate a copy ap.1 = ap, and use &ap.1 as argument.
>>    This means that we have to copy back the ap.1 value to ap after IFN_VA_ARG.
>>    The copy is classified by the va_list_gpr/fpr_size optimization as an
>>    escape,  so it inhibits optimization. The tree-ssa/stdarg-2.c f15 update is
>>    because of that.
>>
>> OK for stage1?
>
> Looks mostly good, though it looks like with -O0 this doesn't delay
> lowering of va-arg and thus won't "fix" offloading.  Can you instead
> introduce a PROP_gimple_lva, provide it by the stdarg pass and add
> a pass_lower_vaarg somewhere where pass_lower_complex_O0 is run
> that runs of !PROP_gimple_lva (and also provides it), and require
> PROP_gimple_lva by pass_expand?  (just look for PROP_gimple_lcx for
> the complex stuff to get an idea what needs to be touched)
>

Updated according to comments.

Furthermore (having updated the patch series to recent trunk), I'm dropping the 
ACCEL_COMPILER bit in pass_stdarg::gate. AFAIU the comment there relates to this 
patch.

Retested as before.

OK for stage1?

Btw, I'm wondering if as run-time optimization we can tentatively set 
PROP_gimple_lva at the start of the gimple pass, and unset it in 
gimplify_va_arg_expr. That way we would avoid the loop in expand_ifn_va_arg_1 
(over all bbs and gimples) in functions without va_arg.

Thanks,
- Tom