From: Tom de Vries <Tom_deVries@mentor.com>
To: Richard Biener <rguenther@suse.de>
Cc: Jakub Jelinek <jakub@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Michael Matz <matz@suse.de>
Subject: [PING^2] [PATCH][5a/5] Postpone expanding va_arg until pass_stdarg
Date: Thu, 16 Apr 2015 08:50:00 -0000 [thread overview]
Message-ID: <552F77B4.7050406@mentor.com> (raw)
In-Reply-To: <54FF0E2C.6080602@mentor.com>
[stage1 ping^2]
On 10-03-15 16:30, Tom de Vries wrote:
> [stage1 ping]
> On 22-02-15 14:13, Tom de Vries wrote:
>> 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?
>>
>
> Ping.
Ping again.
Patch originally posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01332.html .
Thanks,
- Tom
>> 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.
>>
>
> Taken care of in follow-up patch 5b.
next prev parent reply other threads:[~2015-04-16 8:50 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 10:48 [stage1] " Tom de Vries
2015-02-19 10:51 ` [PATCH][1/5] Disable lang_hooks.gimplify_expr in free_lang_data Tom de Vries
2015-02-19 12:41 ` Richard Biener
2015-02-19 10:59 ` [PATCH][2/5] Add gimple_find_sub_bbs Tom de Vries
2015-02-19 12:41 ` Richard Biener
2015-02-19 12:51 ` Jakub Jelinek
2015-02-19 13:03 ` Marek Polacek
2015-02-19 13:31 ` Richard Biener
2015-02-19 13:07 ` Richard Biener
2015-02-22 12:47 ` Tom de Vries
2015-02-19 11:06 ` [PATCH][3/5] Factor optimize_va_list_gpr_fpr_size out of pass_stdarg::execute Tom de Vries
2015-02-19 12:44 ` Richard Biener
2015-02-19 11:37 ` [PATCH][4/5] Handle internal_fn in operand_equal_p Tom de Vries
2015-02-19 12:49 ` Richard Biener
2015-02-19 12:59 ` Jakub Jelinek
2015-02-19 13:09 ` Richard Biener
2015-02-19 15:31 ` Tom de Vries
2015-02-20 11:59 ` Richard Biener
2015-02-22 13:13 ` Tom de Vries
2015-02-23 10:19 ` Richard Biener
2015-02-24 13:09 ` Fwd: " Tom de Vries
2015-02-19 12:08 ` [PATCH][5/5] Postpone expanding va_arg until pass_stdarg Tom de Vries
2015-02-19 13:05 ` Richard Biener
2015-02-22 13:24 ` Tom de Vries
2015-02-23 9:03 ` Michael Matz
2015-02-23 10:36 ` Tom de Vries
2015-02-24 8:26 ` Tom de Vries
2015-03-10 15:31 ` [PING] [PATCH][5b/5] Avoid running expand_ifn_va_arg_1 in functions without va_arg Tom de Vries
2015-04-16 8:50 ` [PING^2] " Tom de Vries
2015-04-16 8:56 ` Richard Biener
2015-03-10 15:31 ` [PING] [PATCH][5a/5] Postpone expanding va_arg until pass_stdarg Tom de Vries
2015-04-16 8:50 ` Tom de Vries [this message]
2015-04-16 8:55 ` [PING^2] " Richard Biener
2015-04-21 5:32 ` Bin.Cheng
2015-06-09 11:04 ` Alan Lawrence
2015-06-09 11:07 ` Richard Biener
2015-06-09 13:03 ` Tom de Vries
2015-06-09 13:07 ` Richard Biener
2015-06-09 13:30 ` Alan Lawrence
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=552F77B4.7050406@mentor.com \
--to=tom_devries@mentor.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=matz@suse.de \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).