public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Alan Lawrence <alan.lawrence@arm.com>
Cc: Tom de Vries <Tom_deVries@mentor.com>,
	Jakub Jelinek <jakub@redhat.com>,
	    GCC Patches <gcc-patches@gcc.gnu.org>,
	Michael Matz <matz@suse.de>
Subject: Re: [PING^2] [PATCH][5a/5] Postpone expanding va_arg until pass_stdarg
Date: Tue, 09 Jun 2015 11:07:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1506091301120.30088@zhemvz.fhfr.qr> (raw)
In-Reply-To: <5576C67E.9070202@arm.com>

On Tue, 9 Jun 2015, Alan Lawrence wrote:

> Hmmm. One side effect of this is that the line number information available in
> the target hook gimplify_va_arg_expr, is now just the name of the containing
> function, rather than the specific use of va_arg. Is there some way to get
> this more precise location (e.g. gimple_location(stmt) in expand_ifn_va_arg_1,
> the only caller of said hook)? I don't really want to have to add an extra
> parameter to the target hook...

The x86 variant doesn't use any locations but if then the caller of
the target hook (expand_ifn_va_arg_1) should assign the IFNs location
to all statements expanded from it (it could set input_location to 
that during the target hook call...)

Richard.

> --Alan
> 
> Richard Biener wrote:
> > On Thu, 16 Apr 2015, Tom de Vries wrote:
> > 
> > > [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 .
> > 
> > Ok.
> > 
> > Thanks,
> > Richard.
> > 
> > > 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.
> > 
> > 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)

  reply	other threads:[~2015-06-09 11:04 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         ` [PING^2] " Tom de Vries
2015-04-16  8:55           ` Richard Biener
2015-04-21  5:32             ` Bin.Cheng
2015-06-09 11:04             ` Alan Lawrence
2015-06-09 11:07               ` Richard Biener [this message]
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=alpine.LSU.2.11.1506091301120.30088@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=Tom_deVries@mentor.com \
    --cc=alan.lawrence@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=matz@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).