similar to: [LLVMdev] How to specify the arm subtarget instruction set in a pass or an arm-backend?

Dear developers! I’d like to ask you a question concerning the implementation of one algorithm for the generation of energy-efficient code for ARM processors. Unfortunately, the documentation on this subject is incomplete on your site, so could you please explain how to implement my algorithm. Without going into details, I would like to say, that the implementation of this algorithm

Dear developers! I’d like to ask you a question concerning the implementation of one algorithm for the generation of energy-efficient code for ARM processors. Unfortunately, the documentation on this subject is incomplete on your site, so could you please explain how to implement my algorithm. Without going into details, I would like to say, that the implementation of this algorithm

[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

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

Hi all, I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

Hello, Nathan >   I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

On 03/02/2010, at 10:16 PM, Anton Korobeynikov wrote: > Hello, Nathan > >> I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit

Hi all, I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. What motivated this? Well this: http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are

I am working on an LLVM backend for the AVR architecture, and am having troubles working with the codegen layer, trying to get around the quirks of the binary encodings of the AVR ISR. There are several different families of AVR microcontrollers, each with a minimum 'core' instruction set. Each family builds upon (or removes) the core ISR with more instructions or different encodings. My

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file

> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. > > What motivated this? Well this: > http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM > > I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts.

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

Hi James, Thanks for the answer, can you elaborate on difference between thumb, thumb2, ARM, thumbv7. I'm a bit lost right now. When specifying thumbv7 llc will generate thumb only code, not thumb2 ? Best Regards Seb > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, May 29,

Well how about as a strawman... taking some options from http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores and http://en.wikipedia.org/wiki/List_of_applications_of_ARM_cores LLVM Supports: ARMv4T -> ARM7TDMI ARMv5TE -> ARM926EJ-S -> XScale ARMv6 -> ARM1136J(F)-S ARMv6ZK -> ARM1176JZ(F)-S ARMv7A -> Cortex-A8 Cortex-A9 ARMv7M -> Cortex-M3

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,

Hello everyone, The review http://reviews.llvm.org/D20951 implements initial support for the ARM architecture in LLD. To keep the patch size down, and to avoid the complexities of interworking between ARM and Thumb, there is just enough support for an ARM only Hello World to link and run on ARM Linux [*]. My main aim is to get this functionality committed as the basis of an ARM port and would

Hello, as a newbee, I'd appreciate some support on regression test setup. Specifically, I am interrested in the feature of tail call optimizations for the ARM v6m targets. This feature currently seems to be completely deactivated at the moment (v6m being based on thumb1 ?!). According to my code-reading, this feature will involve some modifications in epilogue generation. My work on a gcc

On 11/05/12 04:56, 陳韋任 wrote: >> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. >> >> What motivated this? Well this: >> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM >> >> I believe one of the reason the benchmark numbers are totally

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

If you want to create a version for the mips1 subtarget, going back in time will probably be a lot of work for you. If you want to modify the current version you might try the following: 1) Create a Mips1 predicate and use that to disable instruction patterns that match using non Mips1 instructions. 2) Use soft-float 3) You would need to reenable some commented out code used to implement