On Mon, Jan 20, 2020 at 02:56:00PM +, Christophe Leroy wrote:
> >Nice! Much better.
> >
> >It should be tested on more representative hardware, too, but this looks
> >promising alright :-)
>
> mpc832x (e300c2 core) at 333 MHz:
>
> Before:
>
> gettimeofday:vdso: 235 nsec/call
> clock-get
Hi!
On Thu, Jan 16, 2020 at 05:58:24PM +, Christophe Leroy wrote:
> On a powerpc8xx, with current powerpc/32 ASM VDSO:
>
> gettimeofday:vdso: 907 nsec/call
> clock-getres-realtime:vdso: 484 nsec/call
> clock-gettime-realtime:vdso: 899 nsec/call
>
> The first patch adds VDSO gener
Hi!
On Thu, Jan 16, 2020 at 03:54:58PM +, David Laight wrote:
> if you are trying to 'loop carry' the 'carry flag' with 'add with carry'
> instructions you'll almost certainly need to write the loop in asm.
> Since the loop itself is simple, this probably doesn't matter.
Agreed.
> However a
Hi!
On Thu, Jan 16, 2020 at 07:11:36AM +0100, Christophe Leroy wrote:
> I'm trying to see if we could enhance TCP checksum calculations by
> splitting inline assembly blocks to give GCC the opportunity to mix it
> with other stuff, but I'm getting difficulties with the carry.
>
> As far as I ca
On Thu, Jan 16, 2020 at 09:06:08AM +0100, Gabriel Paubert wrote:
> On Thu, Jan 16, 2020 at 07:11:36AM +0100, Christophe Leroy wrote:
> > Hi Segher,
> >
> > I'm trying to see if we could enhance TCP checksum calculations by splitting
> > inline assembly blocks to give GCC the opportunity to mix it
On Tue, Jan 14, 2020 at 05:53:41AM -0600, Timur Tabi wrote:
> On 1/14/20 2:29 AM, Segher Boessenkool wrote:
> >You have no working lswx I suppose?:-)
>
> I don't know if the P4080 supports lswx, but it does, than that would be
> an elegant way to fix this bug.
No e500 ver
On Mon, Jan 13, 2020 at 07:10:11PM -0600, Timur Tabi wrote:
> Ah, I see now. This is all coming back to me.
>
> I would prefer that ev_byte_channel_send() is updated to access only
> 'count' bytes. If that means adding a memcpy to the
> ev_byte_channel_send() itself, then so be it. Trying to
On Fri, Jan 10, 2020 at 07:45:44AM +0100, Christophe Leroy wrote:
> Le 09/01/2020 à 21:07, Segher Boessenkool a écrit :
> >It looks like the compiler did loop peeling. What GCC version is this?
> >Please try current trunk (to become GCC 10), or at least GCC 9?
>
> It is wi
On Thu, Jan 09, 2020 at 05:52:34PM +, Christophe Leroy wrote:
> Wondering why we get something so complicated/redundant for
> vdso_read_begin()
>
> static __always_inline u32 vdso_read_begin(const struct vdso_data *vd)
> {
> u32 seq;
>
> while ((seq = READ_ONCE(vd->seq)) & 1)
>
On Tue, Dec 24, 2019 at 08:15:11PM +0800, Andy Lutomirski wrote:
> Does power have PC-relative data access? If so, I wonder if the code can be
> arranged so that even the array accesses don’t require computing an absolute
> address at any point.
Not before ISA 3.0 (that is Power9).
The bcl/mfl
Hi!
On Fri, Dec 13, 2019 at 11:07:55PM +1100, Michael Ellerman wrote:
> I tried this:
>
> > @@ -295,6 +296,23 @@ void __write_once_size(volatile void *p, void *res,
> > int size)
> > */
> > #define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
> >
> > +#else /* GCC_VERSION < 40800 */
> > +
> > +#d
On Thu, Dec 12, 2019 at 09:41:32AM -0800, Linus Torvalds wrote:
> Yeah, I know, but this really wants a comment. Sadly it looks like gcc
> bugzilla is down, so
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>
> currently gives an "Internal Server Error" for me.
We're being DoSsed agai
Hi,
On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote:
> Some of the generic versions don't generate good code compared to our
> versions, but that's because READ_ONCE() is triggering stack protector
> to be enabled.
The *big* difference is the generic code has a special path that
Hi!
On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> What do you mean by NX ?
It is the Power9 "Nest Accelerator". The patch series should ideally
mention that right at the start, yeah.
> Up to now, NX has been standing for No-eXecute. That's a bit in segment
> registers on
On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote:
> Le 06/12/2019 à 21:59, Segher Boessenkool a écrit :
> >If the compiler can see the callee wants the same TOC as the caller has,
> >it does not arrange to set (and restore) it, no. If it sees it may be
> &
Hi,
On Thu, Dec 05, 2019 at 07:37:24PM -0600, Frank Rowand wrote:
> On 12/3/19 12:35 PM, Segher Boessenkool wrote:
> > Btw. Some OFs mangle the phandles some way, to make it easier to catch
> > people using it as an address (and similarly, mangle ihandles differently,
> > s
On Wed, Dec 04, 2019 at 05:32:54AM +0100, Christophe Leroy wrote:
> Le 29/11/2019 à 19:46, Segher Boessenkool a écrit :
> >The existing call_do_irq isn't C code. It doesn't do anything with r2,
> >as far as I can see; __do_irq just gets whatever the caller of call_do_irq
Hi!
On Tue, Dec 03, 2019 at 03:03:22PM +1100, Michael Ellerman wrote:
> Sebastian Andrzej Siewior writes:
> I've certainly heard it said that on some OF's the phandle was just ==
> the address of the internal representation, and I guess maybe for SLOF
> that is true.
It is (or was). In many OFs
Hi!
On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
> >On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> >>So what do we do ? We just drop the "r2" clobber ?
> >
> >Y
On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> So what do we do ? We just drop the "r2" clobber ?
You have to make sure your asm code works for all ABIs. This is quite
involved if you do a call to an external function. The compiler does
*not* see this call, so you will have
On Mon, Nov 25, 2019 at 09:32:23PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> >> > +static inline void call_do_irq(struct pt_regs *regs, void *sp)
> >> > +{
> >> > +register unsigned long r3 asm("r3") = (unsigned long)reg
On Thu, Nov 21, 2019 at 05:14:45PM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> That breaks 64-bit with GCC9:
>
> arch/powerpc/kernel/irq.c: In function 'do_IRQ':
> arch/powerpc/kernel/irq.c:650:2: error: PIC register clobbered by 'r2' in
> 'asm'
> 650 | asm volatile(
>
On Tue, Nov 05, 2019 at 07:04:04AM +0100, Christophe Leroy wrote:
> Le 04/11/2019 à 20:43, Segher Boessenkool a écrit :
> >Please send this separately, to be committed right now? It is a bug fix,
> >independent of the rest of the series.
>
> Patch 4/6 needs it, as it drops
On Mon, Nov 04, 2019 at 01:32:53PM +1100, Alastair D'Silva wrote:
> When calling flush_icache_range with a size >4GB, we were masking
> off the upper 32 bits, so we would incorrectly flush a range smaller
> than intended.
>
> This patch replaces the 32 bit shifts with 64 bit ones, so that
> the fu
On Wed, Oct 30, 2019 at 10:55:03PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> >> Some of our scripts are passed $objdump and then call it as
> >> "$objdump". This doesn
On Tue, Oct 29, 2019 at 02:15:39PM -0700, Kees Cook wrote:
> On Tue, Oct 15, 2019 at 06:54:13PM +0200, Borislav Petkov wrote:
> > On Fri, Oct 11, 2019 at 11:25:52AM -0500, Segher Boessenkool wrote:
> > > Names *matter*, internal names doubly so. So why replace a good name with
On Sun, Oct 27, 2019 at 10:21:25AM +0100, Christophe Leroy wrote:
> Le 27/10/2019 à 01:06, Segher Boessenkool a écrit :
> >The hand-optimised asm code will pretty likely win handsomely, whatever
> >you do. Especially on cores like the 885 (no branch prediction, single
> >iss
On Sat, Oct 26, 2019 at 08:48:27PM +0200, Thomas Gleixner wrote:
> On Sat, 26 Oct 2019, Christophe Leroy wrote:
> Let's look at the code:
>
> __cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
> {
> const struct vdso_data *vd = __arch_get_vdso_data();
>
> i
On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> >> When booting under OF the zImage expects the initrd address and
On Thu, Oct 24, 2019 at 11:47:30AM +1100, Michael Ellerman wrote:
> Some of our scripts are passed $objdump and then call it as
> "$objdump". This doesn't work if it contains spaces because we're
> using ccache, for example you get errors such as:
>
> ./arch/powerpc/tools/relocs_check.sh: line 4
On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> When booting under OF the zImage expects the initrd address and size to be
> passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU)
> currently doesn't do this so the zImage is not aware of the initrd
> locatio
On Mon, Oct 21, 2019 at 10:15:29PM -0700, Nathan Chancellor wrote:
> On Fri, Oct 18, 2019 at 03:02:10PM -0500, Segher Boessenkool wrote:
> > I think the proper solution is for the kernel to *do* use -ffreestanding,
> > and then somehow tell the kernel that memcpy etc. a
On Fri, Oct 18, 2019 at 12:00:22PM -0700, Nathan Chancellor wrote:
> Just as an FYI, there was some more discussion around the availablity
> and use of bcmp in this LLVM bug which spawned
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp").
>
> https://bugs.llvm.org/show_bug.cgi?id=4103
On Mon, Oct 14, 2019 at 08:56:12AM -0700, Nick Desaulniers wrote:
> On Mon, Oct 14, 2019 at 2:35 AM Segher Boessenkool
> wrote:
> >
> > On Sun, Oct 13, 2019 at 07:51:01PM -0700, Nathan Chancellor wrote:
> > > r374662 gives LLVM the ability to convert certain loops int
On Sun, Oct 13, 2019 at 07:51:01PM -0700, Nathan Chancellor wrote:
> r374662 gives LLVM the ability to convert certain loops into a reference
> to bcmp as an optimization; this breaks prom_init_check.sh:
When/why does LLVM think this is okay? This function has been removed
from POSIX over a decad
On Fri, Oct 11, 2019 at 09:11:43AM -0700, Kees Cook wrote:
> On Fri, Oct 11, 2019 at 03:25:19AM -0500, Segher Boessenkool wrote:
> > On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
> > > The Program Header identifiers are internal to the linker scripts. In
> >
On Thu, Oct 10, 2019 at 05:05:41PM -0700, Kees Cook wrote:
> The Program Header identifiers are internal to the linker scripts. In
> preparation for moving the NOTES segment declaration into RO_DATA,
> standardize the identifier for the PT_NOTE entry to "note" as used by
> all other architectures t
On Thu, Sep 19, 2019 at 07:23:18AM +0200, Christophe Leroy wrote:
> Le 18/09/2019 à 18:39, Segher Boessenkool a écrit :
> >I realise the original code had this... Loading the old stack pointer
> >value back from the stack creates a bottleneck (via the store->load
> >forw
able.
I don't know if using functions as an "i" works properly... It probably
does, it's just not something that you see often :-)
What about r2? Various ABIs handle that differently. This might make
it impossible to share implementation between 32-bit and 64-bit for this.
But we could add it to the clobber list worst case, that will always work.
So anyway, it looks to me like it will work. Nice cleanup. Would be
better if you could do the call to __do_irq from C code, but maybe we
cannot have everything ;-)
Reviewed-by: Segher Boessenkool
Segher
On Tue, Sep 10, 2019 at 02:55:27PM +, Christophe Leroy wrote:
> arch/powerpc/kernel/ contains 7 files dedicated to kexec.
>
> Move them into a dedicated subdirectory.
> arch/powerpc/kernel/{ => kexec}/ima_kexec.c| 0
> arch/powerpc/kernel/{ => kexec}/kexec_32.S | 2 +-
> ar
erated
code a little shorter.
Signed-off-by: Segher Boessenkool
[1] See
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-returns_005ftwice-function-attribute
---
arch/powerpc/include/asm/setjmp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/
On Wed, Sep 04, 2019 at 01:23:36PM +1000, Alastair D'Silva wrote:
> > Maybe also add "msr" in the clobbers.
> >
> Ok.
There is no known register "msr" in GCC.
Segher
On Wed, Sep 04, 2019 at 08:16:45AM +, David Laight wrote:
> From: Nathan Chancellor [mailto:natechancel...@gmail.com]
> > Fair enough so I guess we are back to just outright disabling the
> > warning.
>
> Just disabling the warning won't stop the compiler generating code
> that breaks a 'user'
On Mon, Sep 02, 2019 at 10:55:53PM -0700, Nathan Chancellor wrote:
> On Thu, Aug 29, 2019 at 09:59:48AM +, David Laight wrote:
> > From: Nathan Chancellor
> > > Sent: 28 August 2019 19:45
> > ...
> > > However, I think that -fno-builtin-* would be appropriate here because
> > > we are providing
On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> >(Why are they separate though? It could just be one loop var).
>
> Yes it could just be a single loop var, but in that case it would have
> to be reset a
On Tue, Sep 03, 2019 at 04:28:09PM +0200, Christophe Leroy wrote:
> Le 03/09/2019 à 15:04, Segher Boessenkool a écrit :
> >On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> >>+ asm volatile(
> >>+ " mtctr %2;"
> >>+
Hi!
On Tue, Sep 03, 2019 at 03:23:57PM +1000, Alastair D'Silva wrote:
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> +#if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64)
Please write that as &&? That is more usual, and thus, easier to read.
> +static void flush_dcache_icache_
On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:
> Michal Suchanek writes:
> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> > less so on littleendian.
>
> I think the toolchain people will tell you that there is no 32-bit
> little endian ABI defined at
On Mon, Sep 02, 2019 at 11:48:59AM +1000, Michael Ellerman wrote:
> "Alastair D'Silva" writes:
> > On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:
> >> Can we be 100% sure that GCC won't add any code accessing some
> >> global data or stack while the Data MMU is OFF ?
> >
> > +mpe
> >
>
On Thu, Aug 29, 2019 at 07:38:01PM +1000, Nicholas Piggin wrote:
> So... this actually seems to work. Haven't booted it, but the compiler
> seems to do what we want.
>From the GCC manual:
After defining a global register variable, for the current compilation
unit:
* If the register is
On Wed, Aug 28, 2019 at 03:16:19PM -0700, Nick Desaulniers wrote:
> That's a good reason IMO. IIRC, the -fno-builtin-* flags don't warn
> if * is some unrecognized value, so -fno-builtin-setjmp may not
> actually do anything, and you may need to scan the source (of clang or
> llvm).
-fno-builtin-
On Tue, Aug 27, 2019 at 08:33:45PM +0200, Christophe Leroy wrote:
> >So
> > asm("add%I2 %0,%1,%2" : "=r"(dst) : "r"(src1), "ri"(src1));
>
> "ri", not "n" as for wrtee ?
"n" means a number. "i" means any constant integer. The difference is
mostly that "n" does not allow relocations. This prob
On Tue, Aug 27, 2019 at 07:36:35PM +0200, Christophe Leroy wrote:
> Le 27/08/2019 à 19:29, Segher Boessenkool a écrit :
> >On Tue, Aug 27, 2019 at 10:48:24PM +1000, Nicholas Piggin wrote:
> >>Christophe Leroy's on August 27, 2019 6:13 pm:
> >>>+#define wrtee
On Tue, Aug 27, 2019 at 10:48:24PM +1000, Nicholas Piggin wrote:
> Christophe Leroy's on August 27, 2019 6:13 pm:
> > +#define wrtee(val) asm volatile("wrtee %0" : : "r" (val) : "memory")
> > +#define wrteei(val)asm volatile("wrteei %0" : : "i" (val) :
> > "memory")
>
> Can you implement
On Tue, Aug 27, 2019 at 01:30:09PM +1000, Nicholas Piggin wrote:
> -435 nospu clone3 ppc_clone3
> +435 32 clone3 ppc_clone3
> sys_clone3
> +435 64 clone3 sys_clone3
> +435 nospu clone3
On Mon, Aug 26, 2019 at 09:41:39PM +1000, Michael Ellerman wrote:
> Given how many 601 users there are, maybe 1?, I think that would be a
> simpler option and avoids complicating the code / binary for everyone
> else.
Or you could remove 601 support altogether?
Segher
On Wed, Aug 21, 2019 at 01:50:52PM +0200, Christophe Leroy wrote:
> Le 21/08/2019 à 13:44, Segher Boessenkool a écrit :
> >Calls are cheap, in principle... It is the LR stuff that can make it
> >slower on some cores, and a lot of calling sequence stuff may have
> >considerab
Hi!
On Wed, Aug 21, 2019 at 02:59:59PM +0530, Santosh Sivaraj wrote:
> except for a couple of calls (1 or 2 nsec reduction), there are no
> improvements in the call times. Or is 10 nsec the minimum granularity??
>
> So I don't know if its even worth updating vdso64 except to keep vdso32 and
> vds
On Mon, Aug 19, 2019 at 08:15:38PM -0700, Nathan Chancellor wrote:
> On Mon, Aug 19, 2019 at 04:19:31AM -0500, Segher Boessenkool wrote:
> > On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> > > When building pseries_defconfig, building vdso32 errors out:
&g
On Mon, Aug 19, 2019 at 05:05:46PM +0200, Christophe Leroy wrote:
> Le 19/08/2019 à 16:37, Segher Boessenkool a écrit :
> >On Mon, Aug 19, 2019 at 04:08:43PM +0200, Christophe Leroy wrote:
> >>Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :
> >>>On Mon, Au
On Mon, Aug 19, 2019 at 04:08:43PM +0200, Christophe Leroy wrote:
> Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :
> >On Mon, Aug 19, 2019 at 01:06:31PM +, Christophe Leroy wrote:
> >>Note that we keep using an assembly text using "twi 31, 0, 0" for
> &g
On Mon, Aug 19, 2019 at 01:58:12PM +, Christophe Leroy wrote:
> -#define LOAD_REG_IMMEDIATE_SYM(reg,expr) \
> - lis reg,(expr)@highest; \
> - ori reg,reg,(expr)@higher; \
> - rldicr reg,reg,32,31; \
> - orisreg,reg,(expr)@__AS_ATHIGH; \
Hi Christophe,
On Mon, Aug 19, 2019 at 01:58:10PM +, Christophe Leroy wrote:
> +.macro __LOAD_REG_IMMEDIATE r, x
> + .if (\x) >= 0x8000 || (\x) < -0x8000
> + __LOAD_REG_IMMEDIATE_32 \r, (\x) >> 32
> + sldi\r, \r, 32
> + .if (\x) & 0x
On Mon, Aug 19, 2019 at 01:06:31PM +, Christophe Leroy wrote:
> Note that we keep using an assembly text using "twi 31, 0, 0" for
> inconditional traps because GCC drops all code after
> __builtin_trap() when the condition is always true at build time.
As I said, it can also do this for condit
On Sun, Aug 18, 2019 at 12:13:21PM -0700, Nathan Chancellor wrote:
> When building pseries_defconfig, building vdso32 errors out:
>
> error: unknown target ABI 'elfv1'
>
> Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a
> powerpc64le toolchain") added these flags to fix building
On Mon, Aug 19, 2019 at 07:40:42AM +0200, Christophe Leroy wrote:
> Le 18/08/2019 à 14:01, Segher Boessenkool a écrit :
> >On Sat, Aug 17, 2019 at 09:04:42AM +, Christophe Leroy wrote:
> >>Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger
> >>of the t(d/w)nei i
Hi Christophe,
On Sat, Aug 17, 2019 at 06:37:50PM +, Christophe Leroy wrote:
> #define BUG() do { \
> + __builtin_trap(); \
GCC will optimise away all code after this, it knows it is unreachable.
But you want
On Sat, Aug 17, 2019 at 09:04:42AM +, Christophe Leroy wrote:
> Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger
> of the t(d/w)nei instruction instead of using directly the
> value of x.
>
> This leads to GCC adding unnecessary pair of addic/subfe.
And it has to, it is passed as an "r"
On Fri, Aug 16, 2019 at 01:01:50PM +, Christophe Leroy wrote:
> - add r3,r3,r5
> +78: add r3,r3,r5
You can use actual names for the labels as well... .Lsomething if you
want it to stay a local symbol only.
Segher
Hi Christophe,
On Tue, Aug 13, 2019 at 09:59:35AM +, Christophe Leroy wrote:
> + rldicr \r, \r, 32, 31
Could you please write this as
sldi\r, \r, 32
? It's much easier to read, imo (it's the exact same instruction).
You can do a lot cheaper sequences if you
On Wed, Aug 14, 2019 at 08:46:15PM +1000, Michael Ellerman wrote:
> Claudio Carvalho writes:
> > +_GLOBAL(ucall_norets)
> > +EXPORT_SYMBOL_GPL(ucall_norets)
> > + mfcrr0
> > + stw r0,8(r1)
> > +
> > + sc 2 /* Invoke the ultravisor */
> > +
> > + lwz r0,8(r1)
On Fri, Aug 09, 2019 at 10:12:56PM +0200, Arnd Bergmann wrote:
> @@ -106,7 +106,7 @@ static inline u##size name(const volatile u##size
> __iomem *addr)\
> { \
> u##size ret;
On Fri, Aug 09, 2019 at 10:03:01PM +0200, Christophe Leroy wrote:
> Arnd Bergmann a écrit :
>
> >On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> >Linux wrote:
> >
> >> static inline void dcbz(void *addr)
> >> {
> >>- __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr)
On Fri, Aug 09, 2019 at 08:28:19PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 9, 2019 at 8:21 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
>
> > static inline void dcbz(void *addr)
> > {
> > - __asm__ __volatile__ ("dcbz %y0" : : "Z"(*(u8 *)addr) : "memory");
> > + __asm__ __
On Tue, Aug 06, 2019 at 10:14:27PM +1000, Michael Ellerman wrote:
> Christopher M Riedl writes:
> > Yep, and that's no good. Hmm, executing the barrier() in the
> > non-shared-processor
> > case probably hurts performance here?
>
> It's only a "compiler barrier", so it shouldn't generate any cod
On Thu, Aug 01, 2019 at 10:26:28PM +1000, Michael Ellerman wrote:
> GCC 9 fails to build some of the ptrace TM tests, with errors such as:
>
> ptrace-tm-spd-vsx.c: In function 'tm_spd_vsx':
> ptrace-tm-spd-vsx.c:51:2: error: listing the stack pointer register 'r1' in
> a clobber list is depre
On Tue, Jul 30, 2019 at 08:24:14PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 6:16 PM Segher Boessenkool
> wrote:
> > in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> > well, its (not byte reversing) read will be atomic just fine, so things
&
On Tue, Jul 30, 2019 at 11:16:37AM -0500, Segher Boessenkool wrote:
> in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> well, its (not byte reversing) read will be atomic just fine, so things
> will still work correctly.
>
> The things defined with DEF_MMIO_I
On Tue, Jul 30, 2019 at 04:30:29PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 30, 2019 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> > > Upon a second look, I think the issue is that the "Z" is a
On Tue, Jul 30, 2019 at 09:34:28AM +0200, Arnd Bergmann wrote:
> Upon a second look, I think the issue is that the "Z" is an input argument
> when it should be an output. clang decides that it can make a copy of the
> input and pass that into the inline asm. This is not the most efficient
> way, bu
On Mon, Jul 29, 2019 at 01:32:46PM -0700, Nathan Chancellor wrote:
> For the record:
>
> https://godbolt.org/z/z57VU7
>
> This seems consistent with what Michael found so I don't think a revert
> is entirely unreasonable.
Try this:
https://godbolt.org/z/6_ZfVi
This matters in non-trivial loo
On Tue, Jul 23, 2019 at 09:21:53AM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> >> can use both RA and RB to compute the address, rather than us forcing RA
> >> to 0.
> >>
> >> But at least with my compiler here (GCC 8 vintage) I don'
On Mon, Jul 22, 2019 at 10:21:07AM -0700, Nick Desaulniers wrote:
> On Sun, Jul 21, 2019 at 11:19 PM Segher Boessenkool
> wrote:
> > On Sun, Jul 21, 2019 at 07:41:40PM -0700, Nathan Chancellor wrote:
> > > On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
&
On Mon, Jul 22, 2019 at 08:15:14PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> >> 017c clear_user_page:
> >> 17c: 94 21 ff f0 stwu 1, -16(1)
On Sun, Jul 21, 2019 at 07:41:40PM -0700, Nathan Chancellor wrote:
> Hi Segher,
>
> On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
> > On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> > > 017c clear_user_page:
>
On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> I have attached the disassembly of arch/powerpc/kernel/mem.o with
> clear_page (working) and broken_clear_page (broken), along with the side
> by side diff. My assembly knowledge is fairly limited as it stands and
> it is certainl
On Thu, Jul 18, 2019 at 08:24:56PM -0700, Nathan Chancellor wrote:
> On Mon, Jul 08, 2019 at 11:49:52PM -0700, Nathan Chancellor wrote:
> > On Tue, Jul 09, 2019 at 07:04:43AM +0200, Christophe Leroy wrote:
> > > Is that a Clang bug ?
> >
> > No idea, it happens with clang-8 and clang-9 though (pre
Hi!
On Thu, Jul 18, 2019 at 11:19:58AM +0900, Masahiro Yamada wrote:
> On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool
> wrote:
> Kbuild always uses thin archives as far as vmlinux is concerned.
>
> But, there are some other call-sites.
>
> masahiro@pug:~/ref/l
(Sorry to hijack your reply).
On Thu, Jul 18, 2019 at 06:11:48PM +1000, Alexey Kardashevskiy wrote:
> On 13/07/2019 16:00, Thiago Jung Bauermann wrote:
> >From: Ram Pai
> >+static int enter_secure_mode(unsigned long kbase, unsigned long fdt)
> >+{
> >+register uint64_t func asm("r3") = UV_ESM
On Thu, Jul 18, 2019 at 12:19:36AM +0900, Masahiro Yamada wrote:
> On Wed, Jul 17, 2019 at 11:38 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > And it'
On Tue, Jul 16, 2019 at 10:15:47PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> And it's definitely calling ar with no flags, eg:
>
> rm -f init/built-in.a; powerpc-linux-ar rcSTPD init/built-in.a init/main.o
> init/version.o init/do_mounts.o init
On Mon, Jul 15, 2019 at 09:03:46PM +0900, Masahiro Yamada wrote:
> On Mon, Jul 15, 2019 at 4:30 PM Segher Boessenkool
> wrote:
> >
> > On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> > > Segher Boessenkool writes:
> > > > Yes, that is w
On Mon, Jul 15, 2019 at 05:05:34PM +1000, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > Yes, that is why I used the environment variable, all binutils work
> > with that. There was no --target option in GNU ar before 2.22.
>
> Yeah, we're not very good
On Sun, Jul 14, 2019 at 07:45:15AM +0900, Masahiro Yamada wrote:
> On Sat, Jul 13, 2019 at 10:17 PM Segher Boessenkool
> wrote:
> > On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> > > On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
>
On Sat, Jul 13, 2019 at 07:47:44AM -0500, Segher Boessenkool wrote:
> On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> > The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> > in a useful way because it is always overridden by the following code
On Sat, Jul 13, 2019 at 12:21:06PM +0900, Masahiro Yamada wrote:
> The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
> in a useful way because it is always overridden by the following code
> in the top Makefile:
>
> # use the deterministic mode of AR if available
> KBUILD_A
On Tue, Jul 09, 2019 at 08:21:54AM +0530, Aneesh Kumar K.V wrote:
> On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
> >I don't think it's that, there's some magic in flush_icache_range() to
> >handle dropping prefetched instructions on 970.
> >
> >>So overall wondering why we need that extra barriers t
ructions (dcbz, dcbi, dcbf and dcbst) take two registers
> >>>that are summed to obtain the target address. Using 'Z' constraint
> >>>and '%y0' argument gives GCC the opportunity to use both registers
> >>>instead of only one with the sec
On Tue, Jul 02, 2019 at 11:16:35AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 03, 2019 at 01:19:34AM +1000, Michael Ellerman wrote:
> > What we could do is switch to the `UL` macro from include/linux/const.h,
> > rather than using our own ASM_CONST.
>
> You need gas 2
On Wed, Jul 03, 2019 at 01:19:34AM +1000, Michael Ellerman wrote:
> What we could do is switch to the `UL` macro from include/linux/const.h,
> rather than using our own ASM_CONST.
You need gas 2.28 or later for that though.
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=86b80085
ht
501 - 600 of 1641 matches
Mail list logo
