similar to: [LLVMdev] A Question to LLVM

On 12 May 2014 15:11, Tim Northover <t.p.northover at gmail.com> wrote: > It sounds like you're using the wrong triple. Even on Windows you > should be able to output ELF if you compile with (say) "clang -target > arm-none-eabi". Or not using a triple at all. Windows on ARM support is coming along, I bet it defaults to WoA and outputs COFF or whatever. cheers,

I gave the following function to IAR compiler (targeting CortexM0) and to clang/LLVM 3.2 (clang -O3 -target thumbv6-eabi -emit-llvm) int calleeSave8(int in[]){ int out=0; int i; for(i=0;i<8;i++){ out ^= in[i] & in[(i+1)%8]; }//expand to out = (in[0]&in[1])^(in[1]&in[2])^(in[2]&in[3])^(in[3]&in[4])^(in[4]&in[5])^(in[5]&in[6])^(in[6]&in[7])^(in[7]&in[0])

Have you tried armv7? -bw On Feb 2, 2013, at 3:50 PM, matic at nimp.co.uk wrote: > I gave the following function to IAR compiler (targeting CortexM0) and to clang/LLVM 3.2 (clang -O3 -target thumbv6-eabi -emit-llvm) > > int calleeSave8(int in[]){ > int out=0; > int i; > for(i=0;i<8;i++){ > out ^= in[i] & in[(i+1)%8]; > }//expand to out =

Hi, clang -O3 -target thumbv7-eabi -emit-llvm ... llc ... -debug -O3 -code-model=small -march=thumb -mcpu=cortex-m3 ... Does generate slightly better code, but it still computes 7 xor + 7 and. Anyway this should be a target independent optimization isn't it ?? Cheers Sebastien On 2013-02-04 16:46, Bill Wendling wrote: > Have you tried armv7? > > -bw > > On Feb 2,

> When you decide to work on MachO/Darwin, I want to discuss the problems with ELF vs. EABI (http://llvm.org/PR18187). Well, I'm doing it now to some extent (working on disentangling the ARM backend's various uses of isTargetIOS, isTargetDarwin, isMoonFull as a starting-point). The thing is, the main advantage of Triples is that they're largely GCC-compatible. Without that

Hi all, one issue found during the NetBSD/ARM tests is the following. Consider this input for EARM: int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } At the moment, this will call __modsi3 and __umodsi3, even though those functions are not part of AAPCS. Should this be considered a lowering bug in the ARM target? Joerg

Hi Joerg, > At the moment, this will call __modsi3 and __umodsi3, even though those > functions are not part of AAPCS. Should this be considered a lowering > bug in the ARM target? LLVM actually supports both variants, depending on the target. The __aeabi_* functions are part of the ARM "runtime ABI" and largely independent of AAPCS. For whatever reason, Linux (& Darwin)

Hi, I didn't do any serious benchmarking but so far I never found a case where LLVM does better than IAR on CortexM0, but I saw a lot of cases where IAR output is better than LLVM... That said I did not use -Os or -Oz, I just used -O3. A recurrent situation is that LLVM push/pop one or two extra registers compared to IAR, I guess it does so in order to comply with a standard ABI or

On 3 May 2017 at 08:01, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can you provide a .s file that shows the difference? I managed to reproduce it by compiling 'char *var = "whatever";' in debug mode (so clang -target arm-none-eabi tmp.c -g"). Direct compile leaves no assembler-local strings, but for some reason going via -S does.

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

On Thu, 15 Nov 2018 at 14:18, Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Ahhh, typo in my previous mail: > > > > when I noticed that -Os gives me Thumb on Cortex-A{8,9,17} > > > I wanted to say: > > > when I noticed that "GCC -Os" gives me Thumb on Cortex-A{8,9,17} > > Yes. Just to clarify my response. That particular linaro

What about benchmarks on other Arm devices? On 02/26/2013 02:52 PM, Jim Grosbach wrote: > Cortex-M0 is a Thumb1 only device. There hasn't been any concerted > effort to tune LLVM's Thumb1 output in quite a long time. Even back then > (2008 or so), the effort was mainly to get it to work acceptably, with > the real performance tuning work being done for Thumb2. I'm not >

Cortex-M0 is a Thumb1 only device. There hasn't been any concerted effort to tune LLVM's Thumb1 output in quite a long time. Even back then (2008 or so), the effort was mainly to get it to work acceptably, with the real performance tuning work being done for Thumb2. I'm not surprised that an embedded market focussed compiler like IAR is better tuned for a chip like that. -Jim On Feb

Hi all, I am trying to cross-compile my application for ARM Cortex-M3. Here's how I'm doing it: 1, Get a pre-built GNU toolchain for ARM Cortex-M processors from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads 2, Create an object file for ARM: clang -c -target arm-none-eabi -mcpu=cortex-m3 -mthumb -O3 -g

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

Hi Gary, On 3 December 2013 22:01, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > The subject of two of his commits dealt with substituting MOVW/MOVT pairs > for an LDR and a lit-pool. Isn't this what MachineConstantPool and > ARMConstantIslandPass was all about? Both are essential components to using lit-pools: the MachineConstantPool is just LLVM's underlying

Thanks for your prompt reply. I didn't build the libc at all, I downloaded a pre-built version of the whole toolchain from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads, so I guess it is an official version provided by ARM and should work? This version targets ARM Cortex-M and Cortex-R family of processors... Son Tuan Vu On Mon, Mar 12, 2018 at 4:15 PM, Tim Northover

Hi, I want to explorer affection of compiler on low power. For the project background, I tend to process this work via LLVM, rather than GCC. And the Target is ARM. For this purpose, clang(3.2) + arm-gcc + simplescalar-arm(and panalyzer) seems to be a good choice. But I encounter several problems in the processing of setup the environment. ---------------------------------- 1. Firstly, arm

> > I assume with target you mean the backend? Consider the x86 backend. It > supports 32bit and 64bit mode, with the GNU x32 ABI in between. There > are three different executable formats support (ELF, PE, MachO) with > different constraints. Some platforms require 32bit alignment of the > stack, others require 128bit alignment. The list goes on. The triple > specifies >

I've not run any on non-iOS devices, and haven't looked at GCC since v4.2.1 due to licensing issues, so I don't have a good feel for comparative benchmarking. -Jim On Feb 26, 2013, at 4:20 PM, Reed Kotler <rkotler at mips.com> wrote: > What about benchmarks on other Arm devices? > > On 02/26/2013 02:52 PM, Jim Grosbach wrote: >> Cortex-M0 is a Thumb1 only