Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible

Hi! On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote: > For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' for > when all bits to be cleared are consecutive. Also on 64-bits, as long as both the top and bottom bits are in the low 32-bit half (for 32 bit mode, it can

Re: [PATCH v1 2/2] powerpc/atomics: Use immediate operand when possible

quot; > + add%I2 %0,%0,%2 \n" > "stwcx. %0,0,%1 \n\ > bne-1b \n" > PPC_ATOMIC_EXIT_BARRIER > -"subf%0,%2,%0 \n\ > +"sub%I2 %0,%0,%2 \n\ > 2:" > - : "=&r" (t) > - : "r" (&v->counter), "r" (a), "r" (u) > + : "=&b" (t) > + : "r" (&v->counter), "rI" (a), "r" (u) > : "cc", "memory"); Same here. Nice patches! Acked-by: Segher Boessenkool Segher

Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR

On Fri, Apr 09, 2021 at 02:36:16PM +1000, Alexey Kardashevskiy wrote: > On 08/04/2021 19:04, Michael Ellerman wrote: > +#define QUERY_DDW_PGSIZE_4K 0x01 > +#define QUERY_DDW_PGSIZE_64K 0x02 > +#define QUERY_DDW_PGSIZE_16M 0x04 > +#define QUERY_DDW_PGSIZE_32M 0x08 >

Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible

On Tue, Apr 13, 2021 at 06:33:19PM +0200, Christophe Leroy wrote: > Le 12/04/2021 à 23:54, Segher Boessenkool a écrit : > >On Thu, Apr 08, 2021 at 03:33:44PM +, Christophe Leroy wrote: > >>For clear bits, on 32 bits 'rlwinm' can be used instead or 'andc' f

Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible

On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote: > Would be nice if we could let the compiler deal with it all... > > static inline unsigned long lr(unsigned long *mem) > { > unsigned long val; > > /* > * This doesn't clobber memory but want to avoid memor

Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible

On Wed, Apr 14, 2021 at 02:42:51PM +0200, Christophe Leroy wrote: > Le 14/04/2021 à 14:24, Segher Boessenkool a écrit : > >On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote: > >>Would be nice if we could let the compiler deal with it all... > >> > &g

Re: [PATCH v1 1/2] powerpc/bitops: Use immediate operand when possible

On Wed, Apr 14, 2021 at 03:32:04PM +, David Laight wrote: > From: Segher Boessenkool > > Sent: 14 April 2021 16:19 > ... > > > Could the kernel use GCC builtin atomic functions instead ? > > > > > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomi

Re: [PATCH v2] powerpc/traps: Enhance readability for trap types

On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote: > So perhaps: > > EXC_SYSTEM_RESET > EXC_MACHINE_CHECK > EXC_DATA_STORAGE > EXC_DATA_SEGMENT > EXC_INST_STORAGE > EXC_INST_SEGMENT > EXC_EXTERNAL_INTERRUPT > EXC_ALIGNMENT > EXC_PROGRAM_CHECK > EXC_FP_UNAVAILABLE

Re: [PATCH v2] powerpc/traps: Enhance readability for trap types

On Thu, Apr 01, 2021 at 10:55:58AM +0800, Xiongwei Song wrote: > Segher Boessenkool 于2021年4月1日周四 上午6:15写道： > > > On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote: > > > So perhaps: > > > > > > EXC_SYSTEM_RESET > > &

Re: [PATCH v2] powerpc/traps: Enhance readability for trap types

On Thu, Apr 01, 2021 at 06:01:29PM +1000, Nicholas Piggin wrote: > Excerpts from Michael Ellerman's message of April 1, 2021 12:39 pm: > > Segher Boessenkool writes: > >> On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote: > >>> So perha

Re: PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr

On Sun, Apr 18, 2021 at 06:24:29PM +0200, Christophe Leroy wrote: > Le 17/04/2021 à 22:17, Randy Dunlap a écrit : > >Should the code + Kconfigs/Makefiles handle that kind of > >kernel config or should ALTIVEC always mean PPC_FPU as well? > > As far as I understand, Altivec is completely independan

Re: [PATCH 2/2] powerpc: add ALTIVEC support to lib/ when PPC_FPU not set

Hi! On Sun, Apr 18, 2021 at 01:17:26PM -0700, Randy Dunlap wrote: > Add ldstfp.o to the Makefile for CONFIG_ALTIVEC and add > externs for get_vr() and put_vr() in lib/sstep.c to fix the > build errors. > obj-$(CONFIG_PPC_FPU)+= ldstfp.o > +obj-$(CONFIG_ALTIVEC)+= ldstfp.o It is

Re: [PATCH 2/2] powerpc: add ALTIVEC support to lib/ when PPC_FPU not set

On Mon, Apr 19, 2021 at 03:38:02PM +0200, Christophe Leroy wrote: > Le 19/04/2021 à 15:32, Segher Boessenkool a écrit : > >On Sun, Apr 18, 2021 at 01:17:26PM -0700, Randy Dunlap wrote: > >>Add ldstfp.o to the Makefile for CONFIG_ALTIVEC and add > >>externs for get_vr()

Re: [PATCH 2/2] powerpc: make 'boot_text_mapped' static

Hi! On Thu, Apr 08, 2021 at 07:04:35AM +0200, Christophe Leroy wrote: > Le 08/04/2021 à 03:18, Yu Kuai a écrit : > >-int boot_text_mapped __force_data = 0; > >+static int boot_text_mapped __force_data; > > Are you sure the initialisation to 0 can be removed ? Usually > initialisation to 0 is not

Re: static_branch/jump_label vs branch merging

On Thu, Apr 08, 2021 at 06:52:18PM +0200, Peter Zijlstra wrote: > Is there *any* way in which we can have the compiler recognise that the > asm_goto only depends on its arguments and have it merge the branches > itself? > > I do realize that asm-goto being volatile this is a fairly huge ask, but >

Re: [PATCH v3] powerpc/traps: Enhance readability for trap types

On Fri, Apr 09, 2021 at 06:14:19PM +0200, Christophe Leroy wrote: > >+#define INTERRUPT_SYSTEM_RESET0x100 > > INT_SRESET SRESET exists on many PowerPC, it means "soft reset". Not the same thing at all. I think "INT" is not a great prefix fwiw, there are many things you can abbr to "INT". >

Re: [PATCH v3] powerpc/traps: Enhance readability for trap types

On Sat, Apr 10, 2021 at 11:42:41AM +0200, Christophe Leroy wrote: > Le 10/04/2021 à 02:04, Michael Ellerman a écrit : > >I think these can all be avoided by defining most of the values > >regardless of what platform we're building for. Only the values that > >overlap need to be kept behind an ifdef

Re: static_branch/jump_label vs branch merging

On Fri, Apr 09, 2021 at 12:33:29PM -0700, Nick Desaulniers wrote: > Since asm goto is implicitly volatile qualified, it sounds like > removing the implicit volatile qualifier from asm goto might help? > Then if there were side effects but you forgot to inform the compiler > that there were via an e

Re: [PATCH] powerpc/32: Remove powerpc specific definition of 'ptrdiff_t'

#x27; and 'ssize_t' exactly as powerpc do, so > remove the powerpc specific definitions and fallback on > generic ones. > > Signed-off-by: Christophe Leroy Thanks! Acked-by: Segher Boessenkool Segher

Re: violating function pointer signature

On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote: > I could change the stub from (void) to () if that would be better. Don't? In a function definition they mean exactly the same thing (and the kernel uses (void) everywhere else, which many people find clearer). In a function declar

Re: violating function pointer signature

On Wed, Nov 18, 2020 at 07:31:50PM +0100, Florian Weimer wrote: > * Segher Boessenkool: > > > On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote: > >> I could change the stub from (void) to () if that would be better. > > > > Don't? In a function

Re: violating function pointer signature

On Wed, Nov 18, 2020 at 01:58:23PM -0500, Steven Rostedt wrote: > I wonder if we should define on all architectures a void void_stub(void), > in assembly, that just does a return, an not worry about gcc messing up the > creation of the stub function. > > On x86_64: > > GLOBAL(void_stub) > r

Re: violating function pointer signature

On Wed, Nov 18, 2020 at 02:33:43PM -0500, Steven Rostedt wrote: > On Wed, 18 Nov 2020 13:11:27 -0600 > Segher Boessenkool wrote: > > > Calling this via a different declared function type is undefined > > behaviour, but that is independent of how the function is *defined*.

Re: violating function pointer signature

On Thu, Nov 19, 2020 at 09:36:48AM +0100, Peter Zijlstra wrote: > On Wed, Nov 18, 2020 at 01:11:27PM -0600, Segher Boessenkool wrote: > > Calling this via a different declared function type is undefined > > behaviour, but that is independent of how the function is *defined*. >

Re: violating function pointer signature

On Thu, Nov 19, 2020 at 09:59:51AM -0500, Steven Rostedt wrote: > On Thu, 19 Nov 2020 08:37:35 -0600 > Segher Boessenkool wrote: > > > Note that we have a fairly extensive tradition of defining away UB with > > > language extentions, -fno-strict-overflow, -fno-strict-al

Re: violating function pointer signature

On Thu, Nov 19, 2020 at 05:42:34PM +, David Laight wrote: > From: Segher Boessenkool > > Sent: 19 November 2020 16:35 > > I just meant "valid C language code as defined by the standards". Many > > people want all UB to just go away, while that is *impossible* to

Re: [PATCH v2 3/4] Kbuild: make DWARF version a choice

On Tue, Dec 01, 2020 at 12:38:16PM +0900, Masahiro Yamada wrote: > > We can bump -Wa,-gdwarf-2 to -Wa,-gdwarf-3 since GNU actually emits > > DWARF v3 DW_AT_ranges (see > > https://sourceware.org/bugzilla/show_bug.cgi?id=26850 ) > > This can avoid the `warning: DWARF2 only supports one section per >

Re: [PATCH v2 3/4] Kbuild: make DWARF version a choice

On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote: > Btw, is -gsplit-dwarf at all useful for assembler files? If you invoke the assembler via the compiler, with that flag it still creates separate .o and .dwo files (via objcopy invocations as usual). Whether that is useful depends on i

Re: [PATCH v2 3/4] Kbuild: make DWARF version a choice

On Tue, Nov 24, 2020 at 11:56:02AM -0500, Arvind Sankar wrote: > On Mon, Nov 23, 2020 at 06:33:57PM -0600, Segher Boessenkool wrote: > > On Mon, Nov 23, 2020 at 06:22:10PM -0500, Arvind Sankar wrote: > > > Btw, is -gsplit-dwarf at all useful for assembler files? > >

Re: [PATCH] powerpc/vdso32: Add missing _restgpr_31_x to fix build failure

Hi! On Tue, Mar 09, 2021 at 06:19:30AM +, Christophe Leroy wrote: > With some defconfig including CONFIG_CC_OPTIMIZE_FOR_SIZE, > (for instance mvme5100_defconfig and ps3_defconfig), gcc 5 > generates a call to _restgpr_31_x. > I don't know if there is a way to tell GCC not to emit that call,

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

Hi! On Wed, Mar 10, 2021 at 11:32:20AM +, Mark Rutland wrote: > On Tue, Mar 09, 2021 at 04:05:32PM -0600, Segher Boessenkool wrote: > > On Tue, Mar 09, 2021 at 04:05:23PM +, Mark Rutland wrote: > > > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: &

Re: [PATCH v1 01/15] powerpc/uaccess: Remove __get_user_allowed() and unsafe_op_wrap()

On Tue, Mar 02, 2021 at 09:02:54AM +1100, Daniel Axtens wrote: > Checkpatch does have one check that is relevant: > > CHECK: Macro argument reuse 'p' - possible side-effects? > #36: FILE: arch/powerpc/include/asm/uaccess.h:482: > +#define unsafe_get_user(x, p, e) do {

Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32

On Tue, Mar 02, 2021 at 10:40:03PM +1100, Michael Ellerman wrote: > >> -- Change the unwinder, if it's possible for ppc32. > > > > I don't think it is possible. > > I think this actually is the solution. > > It seems the good architectures have all added support for > arch_stack_walk(), and we ha

Re: [PATCH] Replace __toc_start + 0x8000 with .TOC.

Hi! On Sat, Mar 06, 2021 at 09:14:33PM -0800, Fangrui Song wrote: > TOC relocations are like GOT relocations on other architectures. > However, unlike other architectures, GNU ld's ppc64 port defines .TOC. > relative to the .got output section instead of the linker synthesized > .got input section

Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends

Hi! On Tue, Mar 09, 2021 at 04:05:23PM +, Mark Rutland wrote: > On Thu, Mar 04, 2021 at 03:54:48PM -0600, Segher Boessenkool wrote: > > On Thu, Mar 04, 2021 at 02:57:30PM +, Mark Rutland wrote: > > > It looks like GCC is happy to give us the function-entry

Re: [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script

Hi! Very late of course, and the patch is fine, but: On Mon, Jan 04, 2021 at 01:59:53PM -0700, Nathan Chancellor wrote: > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM > change [1]. > > After another LLVM cha

Re: powerpc: Add an inline function to update HID0

On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote: > > +static inline void update_hid0(unsigned long hid0) > > +{ > > + /* > > +* The HID0 update should at the very least be preceded by a > > +* a SYNC instruction followed by an ISYNC instruction > > +*/ > > + mb();

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > On the 8xx, load latency is 2 cycles and taking branches also takes > 2 cycles. So let's unroll the loop. This is not true for most other 32-bit PowerPC; this patch makes performance worse on e.g. 6xx/7xx/7xxx. Let's not! Seghe

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Wed, Aug 05, 2015 at 09:31:41PM -0500, Scott Wood wrote: > On Wed, 2015-08-05 at 19:30 -0500, Segher Boessenkool wrote: > > On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > > > On the 8xx, load latency is 2 cycles and taking branches also takes > > >

Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop

On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: > > The original loop was already optimal, as the comment said. > > The comment says that bdnz has zero overhead. That doesn't mean the adde > won't stall waiting for the load result. adde is execution serialising on those cores; it *a

Re: [PATCH 02/20] powerpc/8xx: Map linear kernel RAM with 8M pages

On Wed, Aug 12, 2015 at 03:40:56PM +0200, Christophe Leroy wrote: > /* Insert level 1 index */ > rlwimi r11, r10, 32 - ((PAGE_SHIFT - 2) << 1), (PAGE_SHIFT - 2) << 1, > 29 > lwz r11, (swapper_pg_dir-PAGE_OFFSET)@l(r11)/* Get the > level 1 entry */ > + mtcrr1

Re: [PATCH] powerpc32: use stmw/lmw for non volatile registers save/restore

On Mon, May 23, 2016 at 10:46:36AM +0200, Christophe Leroy wrote: > lmw/stmw have a 1 cycle (2 cycles for lmw on some ppc) in addition > and implies serialising, however it reduces the amount of instructions > hence the amount of instruction fetch compared to the equivalent > operation with several

Re: [PATCH] powerpc: inline current_stack_pointer()

On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote: > +static inline unsigned long current_stack_pointer(void) > +{ > + register unsigned long *ptr asm("r1"); > + > + return *ptr; > +} Register asm is only guaranteed to work as input to inline asm. NAK. Segher

Re: [PATCH] powerpc: inline current_stack_pointer()

On Tue, May 24, 2016 at 07:39:59AM +0200, Christophe Leroy wrote: > >>+static inline unsigned long current_stack_pointer(void) > >>+{ > >>+ register unsigned long *ptr asm("r1"); > >>+ > >>+ return *ptr; > >>+} > >Register asm is only guaranteed to work as input to inline asm. NAK. > > > Does

Re: Crypto/nx842: Ignore invalid XER[S0] return error

On Sat, Dec 12, 2015 at 03:01:26PM -0800, Haren Myneni wrote: > On 12/12/2015 12:43 AM, Segher Boessenkool wrote: > > On Fri, Dec 11, 2015 at 07:30:29PM -0800, Haren Myneni wrote: > >> NX842 coprocessor sets 3rd bit in CR register with XER[S0] which is > >> nothin

Re: [PATCH V3 2/2] kprobes: Mark OPTPROBES na for powerpc

On Mon, Jul 20, 2015 at 04:24:22PM +0530, Ananth N Mavinakayanahalli wrote: > There is a potential gain to be had with a direct > jump instead of a breakpoint, but the caveats need to be traded off > with the complexity it brings in. > > For now, mark OPTPROBES na for powerpc. If we haven't yet i

Re: [PATCH v3 2/2] powerpc: add support for csum_add()

On Fri, May 22, 2015 at 02:32:42PM -0500, Scott Wood wrote: > > I'd also have thought that the 64bit C version above would be generally > > 'good'. > > It doesn't generate the addc/addze sequence. At least with GCC 4.8.2, > it does something like: > > mr tmp0, csum > li tm

Re: [v2,2/2] powerpc32: add support for csum_add()

On Fri, May 01, 2015 at 08:00:14PM -0500, Scott Wood wrote: > On Tue, 2015-04-28 at 21:01 +0200, christophe leroy wrote: > > The generated code is most likely different on ppc64. I have no ppc64 > > compiler For reference: yes you do. Just add -m64. > Ideal (short of a 64-bit __wsum) would proba

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote: > (1) Each target defines a set of constraint strings, > (2) A new target hook post-processes the asm_insn, looking for the > new constraint strings. The hook expands the condition prescribed > by the string, adjusting the

Re: [RFC] Design for flag bit outputs from asms

On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote: > On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool > wrote: > > > > Since it is pre-processed, there is no real reason to overlap this with > > the constraints namespace; we could have e.g. "=@[xy]

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote: > Why is GCC building ppc64 object files but telling the linker --oformat elf32- > powerpcle? Are different options somehow being passed to GCC in one case > versus the other? This was changed for GCC 6 in ,

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

On Fri, Nov 06, 2015 at 04:55:49PM -0600, Segher Boessenkool wrote: > On Fri, Nov 06, 2015 at 03:09:40PM -0600, Scott Wood wrote: > > Why is GCC building ppc64 object files but telling the linker --oformat > > elf32- > > powerpcle? Are different options somehow being pass

Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

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-

Re: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C

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

Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.

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

Re: [PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

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_

Re: [PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

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;" > >>+

Re: [PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

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

Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

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

Re: [PATCH 1/2] powerpc: rewrite LOAD_REG_IMMEDIATE() as an intelligent macro

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

Re: [PATCH] powerpc/vdso32: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

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

Re: [PATCH] powerpc: optimise WARN_ON()

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"

Re: [RFC PATCH] powerpc: use __builtin_trap() in BUG/WARN macros.

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

Re: [PATCH 2/2] powerpc: cleanup hw_irq.h

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

Re: [PATCH 2/2] powerpc: cleanup hw_irq.h

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

Re: [PATCH 2/2] powerpc: cleanup hw_irq.h

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

Re: [PATCH] powerpc/time: use feature fixup in __USE_RTC() instead of cpu feature.

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

Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

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'

Re: [PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

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

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

Hi Rasmus, On Thu, Sep 05, 2019 at 01:07:11PM +0200, Rasmus Villemoes wrote: > On 05/09/2019 02.18, Nick Desaulniers wrote: > > Is it too late to ask for a feature test macro? Maybe one already > > exists? > > No, not as far as I know. [ That's not what a feature test macro is; a feature test m

Re: [PATCH v2 2/2] powerpc/kexec: move kexec files into a dedicated subdir.

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

Re: [PATCH v3 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()

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

Re: [PATCH v3 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()

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

Re: [PATCH] powerpc: optimise WARN_ON()

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

Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang

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

Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.

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

Re: [PATCH v3 1/3] powerpc: rewrite LOAD_REG_IMMEDIATE() as an intelligent macro

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

Re: [PATCH v3 3/3] powerpc/64: optimise LOAD_REG_IMMEDIATE_SYM()

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; \

Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.

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

Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.

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

Re: [PATCH] powerpc: Don't add -mabi= flags when building with Clang

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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'

Re: [PATCH v2 03/13] powerpc/prom_init: Add the ESM call to prom_init

(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

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

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

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

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

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

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

Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp

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

Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()

On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote: > Balbir Singh writes: > > Fair enough, my point was that the compiler can help out. I'll see what > > -Wconversion finds on my local build :) > > I get about 43MB of warnings here :) Yes, -Wconversion complains about a lot of thi

Re: [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()

On Wed, Feb 20, 2019 at 10:18:38PM +1100, Michael Ellerman wrote: > Segher Boessenkool writes: > > On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote: > >> Balbir Singh writes: > >> > Fair enough, my point was that the compiler can help out. I'll

Re: ppc64le reliable stack unwinder and scheduled tasks

On Sun, Jan 13, 2019 at 11:33:56PM +1100, Balbir Singh wrote: > On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote: > > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote: > > > Could you please define interesting frame on top a bit more? Usually > &

Re: ppc64le reliable stack unwinder and scheduled tasks

On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote: > Could you please define interesting frame on top a bit more? Usually > the topmost return address is in LR There is no reliable way (other than DWARF unwind info) to find out where the value of LR at function entry currently lives (if

Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS

On Mon, May 06, 2019 at 09:34:55AM +0200, Rasmus Villemoes wrote: > I _am_ bending the C rules a bit with the "extern some_var; asm > volatile(".section some_section\nsome_var: blabla");". I should probably > ask on the gcc list whether this way of defining a local symbol in > inline assembly and r

Re: [PATCH] powerpc/32: Remove memory clobber asm constraint on dcbX() functions

Hi! On Mon, May 06, 2019 at 04:31:38PM +, Christophe Leroy wrote: > However, I've tried your suggestion below and get unnexpected result. > >you can do > > > > __asm__ __volatile__ ("dcbf %0" : : "Z"(addr) : "memory"); > > > >to save some insns here and there. ] This should be "dcbf %y0"

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition

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

Re: [PATCH] powerpc: fix inline asm constraints for dcbz

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

<    1   2   3   4   5   6   >