public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <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:39:00 -0000	[thread overview]
Message-ID: <bug-59501-4-sy9hzTptqa@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 #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> >
> >   if (ix86_force_drap || !ACCUMULATE_OUTGOING_ARGS)
> >     crtl->need_drap = true;
> 
> They are needed for -m32.  Otherwise, we got
> 
> FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -Os -fpic execution test
> FAIL: g++.dg/torture/stackalign/eh-global-1.C  -Os -fpic execution test
> FAIL: g++.dg/torture/stackalign/eh-inline-1.C  -Os -fpic execution test
> FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -Os -fpic execution test

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.


  parent reply	other threads:[~2013-12-19 18:39 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 [this message]
2013-12-19 18:43 ` hjl.tools at gmail dot com
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-sy9hzTptqa@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).