public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59501] [4.9 Regression] Vector Gather with GCC 4.9 2013-12-08 Snapshot
Date: Thu, 19 Dec 2013 18:43:00 -0000 [thread overview]
Message-ID: <bug-59501-4-jeJXQuIZVq@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59501-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59501
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #3)
>
> I'm not saying that ix86_get_drap_rtx should be changed.
> But perhaps:
> /* If the only reason for frame_pointer_needed is that we conservatively
> assumed stack realignment might be needed, but in the end nothing that
> needed the stack alignment had been spilled, clear frame_pointer_needed
> and say we don't need stack realignment. */
> if (stack_realign
> && !crtl->need_drap
> && frame_pointer_needed
> && crtl->is_leaf
> && flag_omit_frame_pointer
> && crtl->sp_is_unchanging
> && !ix86_current_function_calls_tls_descriptor
> && !crtl->accesses_prior_frames
> && !cfun->calls_alloca
> && !crtl->calls_eh_return
> && !(flag_stack_check && STACK_CHECK_MOVING_SP)
> && !ix86_frame_pointer_required ()
> && get_frame_size () == 0
> && ix86_nsaved_sseregs () == 0
> && ix86_varargs_gpr_size + ix86_varargs_fpr_size == 0)
> in ix86_finalize_stack_realign_flags could be tweaked, not to bail out
> always if we have !crtl->need_drap, because then it will be set pretty much
> for all leaf functions. I wonder if we can e.g. ask DF whether the drap reg
> is live at entry, if it isn't live, supposedly we can clear crtl->need_drap
> or ignore it
> for this purpose? Also, I wonder even if we actually need the drap register
> we can't for the leaf functions just avoid the dynamic realignment and
> simply let the prologue set the drap reg to the right value.
It sounds a good idea. BTW, I think we have very decent drap
coverage in gcc testsuite, as long as both -m32 and -m64 are
tested.
next prev parent reply other threads:[~2013-12-19 18:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 22:56 [Bug tree-optimization/59501] New: " freddie at witherden dot org
2013-12-19 13:31 ` [Bug tree-optimization/59501] [4.9 Regression] " rguenth at gcc dot gnu.org
2013-12-19 18:09 ` jakub at gcc dot gnu.org
2013-12-19 18:31 ` hjl.tools at gmail dot com
2013-12-19 18:39 ` jakub at gcc dot gnu.org
2013-12-19 18:43 ` hjl.tools at gmail dot com [this message]
2013-12-30 8:53 ` jakub at gcc dot gnu.org
2013-12-30 9:46 ` jakub at gcc dot gnu.org
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=bug-59501-4-jeJXQuIZVq@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/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).