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 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.