search for: uxtb

I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. I'm thinking in particular about legalizing integer types that need to be promoted to the target register size, i.e., i8 and i16 for ARM promoting to i32....

...34 movt lr, #65535 LBB2_1: @ %bb @ =>This Inner Loop Header: Depth=1 eor.w r3, r0, r1 adds r2, #1 ands r3, r3, #1 it ne eorne.w r1, r1, r9 and.w r3, r1, r12 orr.w r1, lr, r3, lsr #1 it eq lsreq r1, r3, #1 ubfx r0, r0, #1, #7 uxtb r3, r2 cmp r3, #8 bne LBB2_1 @ BB#2: @ %bb8 uxth r0, r1 pop {r7, pc} - after canonicalisation _t3: @ BB#0: @ %bb.nph movw r12, #32768 movs r2, #0 movw r9, #16386 movt r12, #65535 LBB2_1: @ %bb...

On 8 December 2016 at 02:34, Jojo Ma <jojo.ma at linaro.org> wrote: > It would be profitable as well if we could enable the canonicalisation on > it. > sequence before this canonicalisation (ARM): > test: > .fnstart > @ BB#0: @ %entry > movw r1, #65534 > and r1, r0, r1 > ubfx r0, r0, #1, #15 > add r0, r0, r1, lsr #1 > bx lr

On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: > I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. That's true, but doing isel as a purely local approach isn't the best either :-). We'd really like to get to whole-function selection dags at some...

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: >> I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. > > That's true, but doing isel as a purely local approach isn't the best either :-). We'd really like to get to whole-function selection dag...

On 19 December 2016 at 09:58, Jojo Ma <jojo.ma at linaro.org> wrote: > /home/likewise-open/SPREADTRUM/jojo.ma/jojoma/source/llvm/llvm-linaro/llvm/llvm/test/CodeGen/Thumb2/machine-licm.ll:88:10: > error: expected string not found in input > ; CHECK: movw {{(r[0-9])|(lr)}}, #32768 > ^ > <stdin>:56:2: note: scanning from here > movw r12, #32768 > ^ Hi

...n the load is an "any_ext" load. It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but that's too late to affect the live-out info. MachineCSE and MachineSink do not help because the first zero-extend is folded into the load (LDRB), so the redundant zero-extend (UXTB) does not appear to be a CSE. In another case, the zero-extend is also folded into an add (UXTAB), which prevents the add from being selected to a better alternative (UXTAB does not allow immediate operands). > >> For ARM and possibly other RISC-like targets, you simply can't define...

what do you mean by "more optimal instructions" ? -omer On Wed, Nov 16, 2011 at 1:28 AM, Joe Abbey <jabbey at arxan.com> wrote: > I've done a first pass over the past 6 months of changes and some notable > things stood out: > > * The ARM backend has reworked Set Jump Long Jump EH Lowering. > * The ARM backend includes improved support for Cortex-M > *

On Aug 18, 2010, at 10:27 AM, Bob Wilson wrote: >> I tend to think that it isn't worth the compile time to try to microoptimize out every compare, but I could be convinced otherwise if there are important use cases we're failing to handle. I also do think that whole-function selection dags will solve a lot of grossness (e.g. much of codegen prepare) with a very clean model. >

I've done a first pass over the past 6 months of changes and some notable things stood out: * The ARM backend has reworked Set Jump Long Jump EH Lowering. * The ARM backend includes improved support for Cortex-M * The ARM backend adds parsing and encoding ARM/Thumb/Thumb2 assembly There are also many many code generation improvements which select more optimal instructions. Those seemed

...ny_ext" load. > It gets (arbitrarily) selected to LDRB, which zero-extends to 32 bits, but > that's too late to affect the live-out info. > > MachineCSE and MachineSink do not help because the first zero-extend is > folded into the load (LDRB), so the redundant zero-extend (UXTB) does not > appear to be a CSE. In another case, the zero-extend is also folded into an > add (UXTAB), which prevents the add from being selected to a better > alternative (UXTAB does not allow immediate operands). > > > > >> For ARM and possibly other RISC-like targets,...