From: Anton Blanchard <anton@samba.org>
To: Alan Modra <amodra@gmail.com>
Cc: Alexander Graf <agraf@suse.de>,
ulrich.weigand@de.ibm.com, paulus@samba.org,
Scott Wood <scottwood@freescale.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
Date: Wed, 7 Jan 2015 16:12:47 +1100 [thread overview]
Message-ID: <20150107161247.55591e93@kryten> (raw)
In-Reply-To: <20141231122453.GH5183@bubble.grove.modra.org>
Hi Alan,
> Right. This is really an rs6000 backend bug. We describe one of the
> indirect calls that go wrong here as
>
> (call_insn 108 107 109 13 (parallel [
> (set (reg:DI 3 3)
> (call (mem:SI (reg:DI 288) [0 *_67 S4 A8])
> (const_int 64 [0x40])))
> (use (mem:DI (plus:DI (reg/f:DI 287 [ ops_44(D)->update ])
> (const_int 8 [0x8])) [0 S8 A8]))
> (set (reg:DI 2 2)
> (mem/v/c:DI (plus:DI (reg/f:DI 1 1)
> (const_int 40 [0x28])) [0 S8 A8]))
> (clobber (reg:DI 65 lr))
> ]) net/core/skbuff.c:2085 680 {*call_value_indirect_aixdi}
> <notes and arg uses omitted for clarity>
> )
>
> Notice that the RTL contains a "parallel". As you might guess, gcc
> treats the vector of expressions inside the square brackets of the
> parallel as happening "in parallel". Meaning that as far as gcc is
> concerned the toc restore part (third element) happens at the same
> time as the call (first element). So if gcc replaces (reg:DI 1) in
> the toc restore with some other register known to have the same value
> *before* the call, gcc's RTL analysis will conclude that such a
> replacement is valid.
Thanks for looking into this. Does that mean we were just getting lucky
with the previous version:
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm("r1");
return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
}
ie a static register asm instead of a global one. If so the safest fix
for now might be to just eat the overead of a register move:
static inline struct thread_info *current_thread_info(void)
{
unsigned long sp;
asm("mr %0,1": "=r"(sp));
return (struct thread_info *)(sp & ~(THREAD_SIZE-1));
}
Anton
next prev parent reply other threads:[~2015-01-07 5:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1414727247-31838-1-git-send-email-anton__19440.5086375356$1414727300$gmane$org@samba.org>
2014-12-17 1:16 ` [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info Alexander Graf
2014-12-17 3:44 ` Anton Blanchard
2014-12-17 9:27 ` Alexander Graf
2014-12-22 6:49 ` Michael Ellerman
2014-12-18 5:11 ` Michael Ellerman
2014-12-18 6:25 ` Anton Blanchard
2014-12-18 15:02 ` Alexander Graf
2014-12-31 12:24 ` Alan Modra
2015-01-07 5:12 ` Anton Blanchard [this message]
2015-01-07 17:59 ` Scott Wood
2015-01-08 6:36 ` Alan Modra
2014-12-18 14:56 ` Alexander Graf
2014-10-31 3:47 Anton Blanchard
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=20150107161247.55591e93@kryten \
--to=anton@samba.org \
--cc=agraf@suse.de \
--cc=amodra@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
--cc=ulrich.weigand@de.ibm.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 NNTP newsgroup(s).