search for: armsubtarget

I'm working with a Cortex-M3 core which is v7-M profile, and it has udiv and sdiv. bagel Jim Grosbach wrote: > Hello, > > As I understand it, the divide instructions are only available on the > v7-R profile of the v7 architecture. Is that incorrect? > > -Jim

The thumb2 instructions include unsigned and signed divide. Attached are a patch and test routine. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: div.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091201/675cf4c5/attachment.ksh> -------------- next part -------------- An embedded and charset-unspecified text was

...such that they're only used > when they're available. The instruction predicates are the best way to > do that. For now, I would suggest adding a predicate such as > "HasThumb2HardwareDivide" and hooking it up to a command line option to > enable (see UseNEONFP in ARMSubTarget.cpp for an example of how to do > that). You can then auto-enable it when the CPU string is "cortex-m3", > as is done for the UseNEONFP option on the A8 (see the bottom of the > ARMSubtarget::ARMSubtarget() constructor in ARMSubTarget.cpp). > > Thanks for looking at th...

...i16>* align 2 to vld1.16 this was intentional in this change or not. If so, my question is what is the preferable way to inform the Subtarget that it is allowed to use unaligned vector loads/stores when NEON is available, but can't use unaligned accesses generally speaking? A new field in ARMSubtarget? Should the -arm-strict-align flag force expansion even on unaligned vector loads/stores? We got this working by adding a field to ARMSubtarget and changing logic in ARMTargetLowering::allowsUnalignedMemoryAccesses, but I am admittedly not entirely sure of the downstream consequences of this, as...

...lignedMemoryAccesses. As you and Jim mentioned, it looks like the vld1/vst1 instructions should support element aligned access for any armv7 implementation (I'm looking at Table A3-1 ARM Architecture Reference Manual - ARM DDI 0406C). Right now I do not think we have the correct code setup in ARMSubtarget to accurately represent this table. I would propose that we keep the existing field for unaligned access and add a new field for element-aligned access. The AllowsUnAlignedMem field remains as is and it could be used to represent the SCTLR.A column in Table A3-1. The AllowsElementAlignedNEON field...

...one of the patterns using that are supported yet, and that's why we don't see any errors for ARM yet. > How ARM handle this? and I removed all ARM related code in RISCVXXX.cpp, > only keep skeleton for easy debug, please give me some hint, thanks a lot! ARMInstructionSelector has an ARMSubtarget reference called STI. We'll probably have to rename that to Subtarget to support something like this in the future. What you need to do when you run into this kind of error is to add the relevant members to your InstructionSelector. Each target may make slightly different assumptions about wha...

...LICENSE.TXT for details. // //===----------------------------------------------------------------------===// // // This file contains the Thumb-1 implementation of the TargetInstrInfo class. // //===----------------------------------------------------------------------===// +#include "ARMSubtarget.h" #include "Thumb1InstrInfo.h" #include "llvm/CodeGen/MachineFrameInfo.h" #include "llvm/CodeGen/MachineInstrBuilder.h" #include "llvm/CodeGen/MachineMemOperand.h" #include "llvm/CodeGen/MachineRegisterInfo.h" #include "llvm/MC/MCIn...

...t; As you and Jim mentioned, it looks like the vld1/vst1 instructions should > support element aligned access for any armv7 implementation (I'm looking at > Table A3-1 ARM Architecture Reference Manual - ARM DDI 0406C). > > Right now I do not think we have the correct code setup in ARMSubtarget to > accurately represent this table. I would propose that we keep the existing > field for unaligned access and add a new field for element-aligned access. > > The AllowsUnAlignedMem field remains as is and it could be used to represent > the SCTLR.A column in Table A3-1. The Allow...

...le::MinGW32) .StartsWith("netbsd", Triple::NetBSD) + .StartsWith("none", Triple::NoneOS) .StartsWith("openbsd", Triple::OpenBSD) .StartsWith("solaris", Triple::Solaris) .StartsWith("win32", Triple::Win32) Index: lib/Target/ARM/ARMSubtarget.cpp =================================================================== --- lib/Target/ARM/ARMSubtarget.cpp (revision 211122) +++ lib/Target/ARM/ARMSubtarget.cpp (working copy) @@ -264,7 +264,7 @@ default: if ((isTargetIOS() && isMClass()) || (TargetTriple.isOSBinForm...

hi, i am trying to find out all the Triple (CPU information) of all the ARM subtargets supported by LLVM 3.3. to do this, i traced all the calls to class ARMSubtarget(), because this class initialized the Triple. i supposed that all the ARM machines need to initialize their own Triple info with ARMSubtarget(). however, to my frustrated, this doesnt seem true, and i still cannot find them anywhere in the source code. i looked at the table gen file lib/Target/ARM...

...e glad to know the code place where we start differentiating between > cortex-a8 and cortex-a15 for code generation. Probably most relevant is the combination of features given to each processor in lib/Target/ARM/ARM.td. This vmul/vmla difference comes from "FeatureHasSlowFPVMLx", via ARMSubtarget.h's useFPVMLx and ARMInstrInfo.td's UseFPVMLx. Cheers. Tim.

On 28 July 2015 at 17:52, Sumanth Gundapaneni <sgundapa at codeaurora.org> wrote: > Android bionic libc doesn’t provide a __modsi3, instead it provides > “__aeabi_idivmod”. Hi Sumanth, Have a look at ARMSubtarget.h, functions: bool isTargetAEABI() They control the lowering of DIV/MOD calls in ARMISelLowering.cpp. Maybe Android needs to be in? cheers, --renato

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides

...u and Jim mentioned, it looks like the vld1/vst1 instructions > should support element aligned access for any armv7 implementation > (I'm looking at Table A3-1 ARM Architecture Reference Manual - ARM DDI 0406C). > > Right now I do not think we have the correct code setup in > ARMSubtarget to accurately represent this table. I would propose that > we keep the existing field for unaligned access and add a new field for element-aligned access. > > The AllowsUnAlignedMem field remains as is and it could be used to > represent the SCTLR.A column in Table A3-1. The > Al...

...ooks like the vld1/vst1 instructions >> should support element aligned access for any armv7 implementation >> (I'm looking at Table A3-1 ARM Architecture Reference Manual - ARM DDI > 0406C). >> >> Right now I do not think we have the correct code setup in >> ARMSubtarget to accurately represent this table. I would propose that >> we keep the existing field for unaligned access and add a new field for > element-aligned access. >> >> The AllowsUnAlignedMem field remains as is and it could be used to >> represent the SCTLR.A column in Tab...

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

Hi, Can someone tell me if my understanding is right in that post-RA scheduler currently assumes no limits on a pipeline's issue width? If so, is it by design or just overlooked? I have a case for, say, 1-issue pipeline when certain pipeline resource becomes occupied a few clocks after instruction start, but hazard evaluation is done incorrectly as scheduler advances clock not for every

...; >> should support element aligned access for any armv7 implementation > >> (I'm looking at Table A3-1 ARM Architecture Reference Manual - ARM > >> DDI > > 0406C). > >> > >> Right now I do not think we have the correct code setup in > >> ARMSubtarget to accurately represent this table. I would propose that > >> we keep the existing field for unaligned access and add a new field > >> for > > element-aligned access. > >> > >> The AllowsUnAlignedMem field remains as is and it could be used to > >>...

...manufacturers are free to > ignore. I think there are several common use cases for these attributes - 1. to mark what ISA a function is compiled for: (i.e. is it a thumb16/thumb32/ARM?) 2. to constrain the generated code to use specific co-processors. At least for case 2, the ARMTargetMachine/ARMSubtarget contains a distinct set of flags which should be output in the file scope section of the attributes For case 1, I don't know how common it is for the same executable to cross thumb boundaries - (given that16bit thumb has limits on register usage etc..) but I suppose its possible. For now, I ag...

Test case name : >> llvm/projects/test-suite/SingleSource/Benchmarks/Misc/matmul_f64_4x4.c - >> This is a 4x4 matrix multiplication, we can make small changes to make it a >> 3x3 matrix multiplication for making things simple to understand . >> > > This is one very specific case. How does that behave on all other cases? > Normally, every big improvement comes with