similar to: [LLVMdev] Help with subtarget features and context-dependent asm parsers

> /tmp/foo.s:1:2: error: instruction requires: distinct-ops > sllk %r2,%r3,1 > ^ That seems like it would be a good improvement for all targets. > ARM seems to rely on the current MatchOperandParserImpl() behaviour, > so I'm not going to suggest changing it unconditionally. Presumably you switched it and looked at what fell over; do you remember what kind

Tim Northover <t.p.northover at gmail.com> writes: >> /tmp/foo.s:1:2: error: instruction requires: distinct-ops >> sllk %r2,%r3,1 >> ^ > > That seems like it would be a good improvement for all targets. Thanks, sounds like it might be more acceptable than I thought :-) >> ARM seems to rely on the current MatchOperandParserImpl() behaviour,

On Jul 17, 2013, at 10:26 AM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Tim Northover <t.p.northover at gmail.com> writes: >>> /tmp/foo.s:1:2: error: instruction requires: distinct-ops >>> sllk %r2,%r3,1 >>> ^ >> >> That seems like it would be a good improvement for all targets. > > Thanks, sounds

Hi, I try to create a backend to support AsmParser, but it hasn't the red part as below. I find the Mips has this. Do you know how to make it appear? Jonathan #ifdef GET_ASSEMBLER_HEADER #undef GET_ASSEMBLER_HEADER // This should be included into the middle of the declaration of // your subclasses implementation of MCTargetAsmParser. unsigned ComputeAvailableFeatures(uint64_t

Jonathan <gamma_chen at yahoo.com.tw> wrote: > I try to create a backend to support AsmParser, but it hasn't the red part > as below. I find the Mips has this. Do you know how to make it appear? > > Jonathan > > #ifdef GET_ASSEMBLER_HEADER > #undef GET_ASSEMBLER_HEADER > // This should be included into the middle of the declaration of > // your subclasses

Thanks you. I'm new to LLVM backend, so the help is much appreciated. On Sat, Oct 24, 2015 at 2:12 AM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Oct 23, 2015, at 3:36 AM, 李弘宇 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > The first line has the following error message: > > > > sop1-playground.s:1:15: error: invalid immediate:

Hi Andrea, That is because the LR is the fixed register as per the http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf and out_char() function is not the leaf function ,Hence compiler tends to save and restore the LR and the save and restore of register r11 is to align stack for 8 bytes as per ARM EABI. Thanks ~Umesh On Tuesday, October 15, 2013, Umesh Kalappa

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH

Umesh, Makes some sort of sense to me, OTOH: If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH encoding T1 (2 bytes opcode) as opposed to the encoding T2 (which is a 4 bytes opcode). A On Tue, Oct 15, 2013 at 2:59 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote: > Hi

Hello LLVM, Does the community have bots or humans tracking code size for -Os builds? I've noticed troubling regressions lately. Sometime near Nov 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for i586. That's ghastly. This week, the EEMBC matrix01 workload grew by 5% for ARMv7m and 3% for i586. Regards, -steve

> This seems fixable. The custom parsers that are only valid for certain sub targets could easily have an explicit early-exit if the active sub target isn't what it's looking for. Would that be sufficient here? It doesn't look like there are different encodings for the same string so I don't think even that would be necessary. How about partitioning by MRS_APSR and MRS_OtherM

On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 November 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track

On 18 July 2012 14:33, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > but I still haven't figure out how to build for cortex-m3 > > clang -march=armv7-m -mfloat-abi=soft <something missing?> testReference.cpp -c -march should have done the trick. You can also try -mcpu=cortex-m3, or try -ccc-host-triple armv7m-none-gnueabi (or -eabi), and possibly

Hi Graham, Thank you for offering help. I am trying to create a reproducer. The problem is that the crashes happen whilst LTO is used. One thing I am sure about IR is broken at compile time. Thanks, Evgeny From: Graham Yiu <gyiu at ca.ibm.com> Date: Friday, 10 November 2017 at 16:09 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: "junbuml at codeaurora.org"

Hi, I'm building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. The system linker dumps the following information when I executed "ld -v" @(#)PROGRAM:ld PROJECT:ld64-241.9 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em LTO support using: LLVM version 3.4.2 which tells me that it is correctly pointing to the LLVM

Forgot to add that all experiments were done with '-O3 -m64 -fexperimental-new-pass-manager'. Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Graham Yiu/Toronto/IBM To: llvm-dev at lists.llvm.org Cc: junbuml at codeaurora.org, xinliangli at gmail.com Date: 11/02/2017 05:26 PM Subject: [RFC]

Hi, I am trying to cross compile code for ARM Cortex m0, m3, and m4. For m0, I use: -target armv6--eabi -mcpu=cortex-m0 That seems to work. For m3 and m4, I use the following which does not work (fatal error: error in backend: CPU: 'cortex-m3' does not support ARM mode): -target armv7m--eabi -mcpu=cortex-m3 and -target armv7em--eabi -mcpu=cortex-m4 Who can help me with the

After a recent upstream pull, my builds for ARM thumbv7 suddenly fail with messages like: error: instruction requires: arm-mode 21 uxtah r6, r0, r6 I use llc with -mtriple=thumbv7-unknown-unknown and llvm-mc with -triple=thumbv7-unknown-unkown. What's the right way to generate thumbv7 binaries? Thanks, -steve

Evan, > I'm the code owner of LLVM codegen and targets. I'm also the one of main developers on the original ARM target. That means, I would make the decisions on major development on ARM target if there are decisions to be made. > > But my role is very different from what people are looking for in this thread. To properly qualify a target like ARM which are supported on many

On Jan 12, 2015, at 2:45 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 10 January 2015 at 17:43, Rahman Lavaee <r.lavaee at gmail.com> wrote: >> Hi, >> I'm building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. >> The system linker dumps the following information when I executed "ld -v" >> >>