All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raymond Jennings <shentino@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jan Kara <jack@suse.cz>, Borislav Petkov <bp@alien8.de>,
	Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support
Date: Mon, 06 Jul 2015 21:01:12 -0700	[thread overview]
Message-ID: <1436241672.5554.2.camel@gmail.com> (raw)
In-Reply-To: <CALCETrVL_24Ao3GndyFN2uGVQttuRf5DpYw0C0iq1x-bKmU2Gg@mail.gmail.com>

On Mon, 2015-07-06 at 10:59 -0700, Andy Lutomirski wrote:
> On Mon, Jul 6, 2015 at 10:40 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> > My reasoning: on modern uarchs there's no penalty for 32-bit misalignment of
> >> > 64-bit variables, only if they cross 64-byte cache lines, which should be rare
> >> > with a chance of 1:16. This small penalty (of at most +1 cycle in some
> >> > circumstances IIRC) should be more than counterbalanced by the compression of
> >> > the stack by 5% on average.
> >>
> >> I'll counter with: what's the benefit?  There are no operations that will
> >> naturally change RSP by anything that isn't a multiple of 8 (there's no pushl in
> >> 64-bit mode, or at least not on AMD chips -- the Intel manual is a bit vague on
> >> this point), so we'll end up with RSP being a multiple of 8 regardless.  Even if
> >> we somehow shaved 4 bytes off in asm, that still wouldn't buy us anything, as a
> >> dangling 4 bytes at the bottom of the stack isn't useful for anything.
> >
> > Yeah, so it might be utilized in frame-pointer less builds (which we might be able
> > to utilize in the future if sane Dwarf code comes around), which does not use
> > push/pop to manage the stack but often has patterns like:
> >
> > ffffffff8102aa90 <SyS_getpriority>:
> > ffffffff8102aa90:       48 83 ec 18             sub    $0x18,%rsp
> >
> > and uses MOVs to manage the stack. Those kinds of stack frames could be 4-byte
> > granular as well.
> >
> > But yeah ... it's pretty marginal.
> 
> To get even that, we'd need an additional ABI-changing GCC flag to
> change GCC's idea of the alignment of long from 8 to 4.  (I just
> checked: g++ thinks that alignof(long) == 8.  I was too lazy to look
> up how to ask the equivalent question in C.)

I just want to point out that long itself is 8 bytes on 64-bit x86, but
only 4 bytes on 32-bit x86.

Perhaps we should keep in mind sizeof(long) and not just alignof(long)?

My opinion btw, is that if long is 8 bytes wide, it should also be 8
bytes aligned.

> --Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



  reply	other threads:[~2015-07-07  4:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-05 20:08 [PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support Andy Lutomirski
2015-07-06 13:44 ` Ingo Molnar
2015-07-06 16:59   ` Andy Lutomirski
2015-07-06 17:40     ` Ingo Molnar
2015-07-06 17:59       ` Andy Lutomirski
2015-07-07  4:01         ` Raymond Jennings [this message]
2015-07-06 17:10   ` Linus Torvalds
2015-07-06 17:32     ` Ingo Molnar

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=1436241672.5554.2.camel@gmail.com \
    --to=shentino@gmail.com \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.