search for: arch_extension

...| ARM | AArch64 | ARM | AArch64 | |----------------------|-----|---------|-----|---------| | -march with '+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can b...

Tim, How about the below option ? 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's features, either locally or upstream. 4. Pass "-mhwdiv=arm,thumb" to Clang (or less if you only have hwdiv in one mode). --Sumanth G -----Original Message----- From: Tim...

...| ARM | AArch64 | ARM | AArch64 | |----------------------|-----|---------|-----|---------| | -march with '+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can b...

...| ARM | AArch64 | ARM | AArch64 | |----------------------|-----|---------|-----|---------| | -march with '+<ext>' | Y | Y | Y | Y | | checks extensions | Y | N | N | N | | .arch with '+<ext>' | N | N | N | Y | | .arch_extension | Y | Y | Y | N | | .fpu | Y | N | Y | N | | -mfpu | Y | N | Y | N | | checks FPUs | N | n/a | N | n/a | |----------------------|-----|---------|-----|---------| Examples of each of these can b...

On 29 January 2015 at 03:36, Tim Northover <t.p.northover at gmail.com> wrote: > These ought to be unneeded if you do 1+2 above. As far as I remember, .arch_extension does change the assembler flags to support whatever you set. Have you tried that? cheers, --renato

...semble code using sdiv/udiv. You probably don't need to combine them. > 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" > 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. This looks like it'd be sufficient (and I didn't know about .arch_extension at all, or I'd have mentioned it. Thanks!). > 3. Teach LLVM & Clang about your CPU's features, either locally or upstream. > 4...

I have pushed the patch here: http://reviews.llvm.org/D7316 Review it and let me know. --Sumanth G > I have tried ".arch_extension" and it works perfectly fine for me. > I will move ahead and add the arch_extension framework to ARM. > > Thanks for your guidance guys. > --Sumanth G > -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: Thursday, January 29, 2015 9...

...n defaulting to warnings behind -Wall. >> - mandatory feature of the base arch is enabled with '+' (option is redundant so is ignored) Agreed, also as discussed above it should not ignore the option. (unless it is actually a nop in that situation or completely impossible) >> .arch_extension was implemented because GCC does it. I'm not sure what you mean by that, but I'm not happy with removing it, as it will break scores of assembly files out there. I put it there to put the choice between being GCC compatible and being consistent within Clang itself. I've quickly realise...

Hi Divacky, I have an armv7 variant that supports hardware division (extension). For my variant, I use ".cpu cortex-a9" and division attribute(.eabi_attribute 44, 2 @ Tag_DIV_use) to let the assembler do the right thing if it encounters a division instruction. With your path, the .cpu directive is used to fetch the available features of a CPU and ignores the eabi attributes. What

...RWONCE_H + +#ifdef CONFIG_CLANG_LTO + +#include <linux/compiler_types.h> +#include <asm/alternative-macros.h> + +#ifndef BUILD_VDSO + +#ifdef CONFIG_AS_HAS_LDAPR +#define __LOAD_RCPC(sfx, regs...) \ + ALTERNATIVE( \ + "ldar" #sfx "\t" #regs, \ + ".arch_extension rcpc\n" \ + "ldapr" #sfx "\t" #regs, \ + ARM64_HAS_LDAPR) +#else +#define __LOAD_RCPC(sfx, regs...) "ldar" #sfx "\t" #regs +#endif /* CONFIG_AS_HAS_LDAPR */ + +#define __READ_ONCE(x) \ +({ \ + int atomic = 1; \ + union { __unqu...

...__ASM_RWONCE_H + +#ifdef CONFIG_LTO + +#include <linux/compiler_types.h> +#include <asm/alternative-macros.h> + +#ifndef BUILD_VDSO + +#ifdef CONFIG_AS_HAS_LDAPR +#define __LOAD_RCPC(sfx, regs...) \ + ALTERNATIVE( \ + "ldar" #sfx "\t" #regs, \ + ".arch_extension rcpc\n" \ + "ldapr" #sfx "\t" #regs, \ + ARM64_HAS_LDAPR) +#else +#define __LOAD_RCPC(sfx, regs...) "ldar" #sfx "\t" #regs +#endif /* CONFIG_AS_HAS_LDAPR */ + +#define __READ_ONCE(x) \ +({ \ + typeof(&(x)) __x = &(x); \ +...

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote: > Why do we care about GAS? We have an assembler. It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The