search for: aarch32

...somewhat misleading I think, -march is used > for specifying an architecture version to target whereas aarch64/arm64 don’t > convey any information to that effect, does it mean armv8a, armv8.1-a, etc? Hi Bradley, That's a good point. But also, what does "armv8a" mean? AArch64? AArch32? I guess we could use the triple (which has aarch64 or arm in it), but then it will need the triple or else we'll have a problem, since the current interpretation of "armv8a" is AArch32. > Personally I’m in favor of having that be rejected, it would be good to have > TargetPa...

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Renato, >...

Hi Junmo, I notice that you recently added the __ARM_FEATURE_DOTPROD pre-defined macro for AArch64. Do you plan on also doing the AArch32 part of this? If not, I'm currently working on adding the corresponding intrinsics to LLVM and clang, so I'll add the macro as part of that. Oliver

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64&q...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.gif>

Hi, A64 versus A32/T32 code generation is controlled by the -target option which I don’t believe is under discussion here. James On 18 May 2016, at 13:17, Bruce Hoult <bruce at hoult.org<mailto:bruce at hoult.org>> wrote: Note that armv8a modifies the A32 and T32 instruction sets, and is therefore an important -march option for 32 bit code. Therefore armv8a can not be used to imply

...sed >> > for specifying an architecture version to target whereas aarch64/arm64 >> don’t >> > convey any information to that effect, does it mean armv8a, armv8.1-a, >> etc? >> >> That's a good point. But also, what does "armv8a" mean? AArch64? AArch32? >> >> I guess we could use the triple (which has aarch64 or arm in it), but >> then it will need the triple or else we'll have a problem, since the >> current interpretation of "armv8a" is AArch32. > > > I agree with you two. Using -march=aarch64/arm6...

...this work I ran into an issue related to llvm in Swiftshader. Currently fixup_aarch64_movw relocation type is not supported for COFF ARM64 (AArch64WinCOFFObjectWriter). As far as I see, Microsoft hasn't defined indicator for this relocation type. I haven't seen documented anywhere. For AArch32 mova/movt indicators were implemented, I'm not sure but maybe we need to have something similar for AArch64? Could someone give me some pointers how I could handle/fix this? Many thanks, Regards, Adam

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F:

...>> >> Currently fixup_aarch64_movw relocation type is not supported for >> COFF ARM64 (AArch64WinCOFFObjectWriter). As far as I see, Microsoft >> hasn't defined indicator for this relocation type. I haven't seen >> documented anywhere. >> >> For AArch32 mova/movt indicators were implemented, I'm not sure but >> maybe we need to have something similar for AArch64? > > The AArch32 movw/movt relocation was for a true relocation, where the > target of the relocation is a symbol that is unknown at the assembly > stage. But for...

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") > + test_target_arch(aarch64

...lib/Target/ARM/ARMRegisterInfo.td is where you > should look into, > > // Integer registers > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > def R1 : ARMReg< 1, "r1">, DwarfRegNum<[1]>; > > ... That's the easy part. ARM (AArch32) has 16 registers because register operands are stored in a 4-bit bitfield in the instructions. If you want to add more registers, then you will also need to modify the instruction encoding of every instruction, or place them in a separate namespace (as with the NEON / VFP registers) and add instr...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/4e949495/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201507161639320_Y2AH3IN3.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/4e949495/attachment.gif>

...ou > > should look into, > > > > // Integer registers > > def R0 : ARMReg< 0, "r0">, DwarfRegNum<[0]>; > > def R1 : ARMReg< 1, "r1">, DwarfRegNum<[1]>; > > > > ... > > That's the easy part. ARM (AArch32) has 16 registers because register operands are stored in a 4-bit bitfield in the instructions. If you want to add more registers, then you will also need to modify the instruction encoding of every instruction, or place them in a separate namespace (as with the NEON / VFP registers) and add instr...

On 3 October 2014 15:20, Evgeniy Stepanov <eugenis at google.com> wrote: > That's a third option. This flag only really makes sense for one or > several test cases in a large GTest file. They can be split and moved > to X86. But this adds more complexity to build system which, in my > opinion, is never good. Roger. > Compiler-rt and llvm build systems know very little

Hi On AArch64 (ARM 64-Bit Platform), I see there is an inconsistency in the values accepted by -march option between clang and llc. --- $ llc -march=aarch64 -mattr=help 2>&1 | grep error $ #No Error $ llc -march=armv8a -mattr=help 2>&1 | grep error llc: error: invalid target 'armv8a'. $ clang -march=armv8a -E - < /dev/null 2>&1 | grep error $ #No Error $

Hello, I’m using NXP layerscape Arch (A53/A72), and I want to use NE 10 Project library , and llvm compiler 3.8.1.1 (https://projectne10.github.io/Ne10/) <https://projectne10.github.io/Ne10/> When compiling the project file I get the following errors : ./NE10_abs.asm.s:59:9: error: unrecognized instruction mnemonic vmov s2, r3 ^ ../NE10_abs.asm.s:62:9: error:

...it. For example, if I specify -march=armv7-a, it *shouldn't* need me > to put "-target arm" before it to work! Good lord, that's horrendous! > On a similar note, how does this proposal deal with instruction set > selection? what does "-march=armv8-a" select- AArch32 or AArch64? or is > that expected to be handled by the "-target" (grim!) Can't we do the same as -thumb? Like -a32 and -a64, with default to -a64? --renato

The ACTLR register is implementation defined. The SMP bit is CA15 and CA7 specific. Also replace ACTLR_CA15_SMP by ACTLR_V7_SMP. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- xen/arch/arm/domain.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index cb0424d..00f2d14 100644 ---

...t before this patch. I just re-used the infrastructure. > > > > ARMv8 shouldn?t need Neon detection at all ? Neon is a mandatory part of the ARMv8 architecture, unlike ARMv7, where it?s optional. > As I understand, your statement for ARMv8 is true for AAarch64 mode. But for ARMv8 in AAarch32 mode, neon is still optional (although I haven't heard of an implementation that does not support NEON even in AAarch32 mode). So, for AArch64 mode, I think rtcd can be disabled. Also, even the neon detection procedure currently in opus will not work on ARMv8 AArch32 mode. Please refer > htt...