similar to: [LLVMdev] where are all the Triple info of ARM subtargets?

So, In order to fix bug PR20787 (common parsing infrastructure for FPU options between LLVM and tools), I need to create a parser in LLVM that has all targets' information (types of fpus, cpus, archs, etc) but that can also be visible by external tools. Until now, all that information has been hidden from view by creating them with TableGen and leave them only visible to the target files.

I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is

OK, here's a patch that follows your suggestion. I'm not an authorized developer, so I can't commit it myself. The test case is also attached again. bagel Jim Grosbach wrote: > Ah, ok. I was comparing v7-A and v7-R only. The M3 is described in > separate documentation (mostly since it lacks the ARM mode instructions, > I suspect). In any case, as far as I can tell, not

Hi Pete, We ran into the same issue with generating vector loads/stores for vectors with less than word alignment. It seems we took a similar approach to solving the problem by modifying the logic in allowsUnalignedMemoryAccesses. 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

I'm implementing this capability to allow switching between mips32 and mips16 code generation on a per function basis (should be useful for arm to thumb switching too). The problem is that while various things are done on a per function basis, there are two passes registered on a per module basis (target lowering and instruction selection). With the new attribute scheme, we can wake up

Thanks Bradley. I see that the features set in /ARM.td/ get written to the generated file /<build>/llvm/lib/Target/ARM/ARMGenSubtargetInfo.inc./ Here the ProcA9 features appear in /ARMFeatureKV/ table: /{ "a9", "Cortex-A9 ARM processors", { ARM::ProcA9 }, { *ARM::FeatureFP16* } }, /With your change, the features for ProcA9 in the above entry are empty.//This

Hello, I have a compiler in LLVM 2.9 for the KCPM3 processor. I'd like to create a subtarget for the new cpu version called KCPSM6. Besides a couple of new instructions which are not important at the moment, the KCPSM6 cpu has different instruction opcodes. Semantically the instructions are the same, hence I'd like to keep all the lowering and pattern matching stuff unmodified For

On 9 March 2015 at 18:21, Reid Kleckner <rnk at google.com> wrote: > To be clear, TargetParser is about parsing subtarget CPUs and features, > right? In the first stage, yes. But there's a lot more. I hope this ends up being a much larger infrastructure to query for target support, not just parsing strings (which we can cope with duplication), but defining architectural behaviour,

Thanks, Alex. See my comments below. On Wed, Aug 23, 2017 at 12:59 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 22 August 2017 at 23:39, Y Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, > > Hi Yonghong. > >> I found some different discrepancy on how Subtarget is created >> between some arch specific TargetMachine constructor.

> -----Original Message----- > From: Bob Wilson [mailto:bob.wilson at apple.com] > Sent: Friday, September 07, 2012 10:57 AM > To: David Peixotto > Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. > > > On Sep 6, 2012, at 4:40 PM, David Peixotto

-----Original Message----- From: Bob Wilson [mailto:bob.wilson at apple.com] Sent: Thursday, September 06, 2012 3:39 PM To: David Peixotto Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Unaligned vector memory access for ARM/NEON. On Sep 6, 2012, at 2:48 PM, David Peixotto <dpeixott at codeaurora.org> wrote:

Hello, Thanks again. We did try overestimating the alignment, and saw the vldr you reference here. It looks like a recent change (r161962?) did enable vld1 generation for this case (great!) on darwin, but not linux. I'm not sure if the effect of lowering load <4 x 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

On Sep 6, 2012, at 2:48 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > Hi Pete, > > We ran into the same issue with generating vector loads/stores for vectors > with less than word alignment. It seems we took a similar approach to > solving the problem by modifying the logic in allowsUnalignedMemoryAccesses. > > As you and Jim mentioned, it looks like the

On Sep 6, 2012, at 4:40 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > -----Original Message----- > From: Bob Wilson [mailto:bob.wilson at apple.com] > Sent: Thursday, September 06, 2012 3:39 PM > To: David Peixotto > Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Unaligned vector

[resending to correct llvm-dev address] Hi, I’d like to start enabling the loop data prefetch pass for Cyclone (an ARM64 subtarget). AFAICT, you can’t really add passes specifically to a subtarget but only to a target. This makes sense because in the new world, you could have different subtargets per function. I just want to make sure my understanding is correct. My plan is to add the pass

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

Hello, I'm implementing a port of LLVM for PowerPC VLE. It's a compressed instruction set similar to mips16 and ARM Thumb. Instruction encoding (VLE/non-vle) is selected for a given memory region by an attribute in a memory area descriptor. Targets supporting this that I know of are all bare-metal (so powerpc-none-elf). I'm trying to implement ELF support right now. VLE ELF files

>> Can I tell tablegen to have two encodings and switch between them >> using a predicate? After some deliberations, I modified tablegen to generate several versions of the GenCodeEmitter file. My tablegen now accepts a new command line parameter called "emitter-instfld". This specifies the name of the field in Instruction that holds the encoded bytes. In my target's td

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use

Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >