public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Bernd Schmidt <bernds@codesourcery.com>,
	       Richard Henderson <rth@redhat.com>,
	gcc@gcc.gnu.org
Subject: Re: Shrink wrapping issues
Date: Sat, 05 Nov 2011 10:50:00 -0000	[thread overview]
Message-ID: <20111105105032.GS1052@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <20111105102818.GH22298@bubble.grove.modra.org>

On Sat, Nov 05, 2011 at 08:58:18PM +1030, Alan Modra wrote:
> On Sat, Nov 05, 2011 at 10:50:44AM +0100, Jakub Jelinek wrote:
> > >From quick look, f1 isn't shrink-wrapped probably because of the set
> > of bb's that need prologue/epilogue around it doesn't end in a return,
> > but in a tail call.  Can't we just add a prologue before the bar call
> > and throw the epilogue away (normally the epilogue in a function that
> > ends only in a tail call is just emitted after the barrier and
> > optimized away I think, we could do the same?).
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00046.html ought to cure
> this particular problem.  With that patch, similar code on
> powerpc-linux does result in shrink wrapping.

I'll try that.

> > And f2 is something that IMHO with especially AVX/AVX2 code happens very
> > often, the prologue is expensive as it realigns the stack.  The reason
> > for that is that until reload we don't know whether something won't be
> > spilled on the stack and we need/want 32-byte aligned stack slots
> > for that spilling.
> 
> Huh?  thread_prologue_and_epilogue is after reload.  So your backend
> ought to be able to figure out whether an aligned stack is needed.

Sure, the backend could figure out.  But it would need to duplicate
parts of what function.c does.  In particular, roughly equivalent of
computing prologue_used and set_up_by_prologue hard regsets (sure, it
doesn't have to necessarily generate the prologue for that), then
the
  FOR_EACH_BB (bb)
    FOR_BB_INSNS (bb, insn)
      if (requires_stack_frame_p (insn, prologue_used,
				  set_up_by_prologue))
	goto needs_prologue;
(and perhaps only do this if -fno-omit-frame-pointer wasn't used, i.e. if
the prologue frame pointer setup was not requested by the user explicitly).
If it is just i?86/x86_64, then perhaps we just should export
requires_stack_frame_p and do it in the backend.  But if it is for more
targets, can't function.c just handle it in the generic code when it
already computes everything needed?

	Jakub

      reply	other threads:[~2011-11-05 10:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-05  9:51 Jakub Jelinek
2011-11-05 10:28 ` Alan Modra
2011-11-05 10:50   ` Jakub Jelinek [this message]

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=20111105105032.GS1052@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rth@redhat.com \
    /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).