search for: ubfx

On Oct 20, 2009, at 10:27 PM, David Conrad wrote: > Hi, > > Currently llvm can generate an invalid sbfx/ubfx op, for instance > when compiling encoder/analyse.c in x264 (I'll reduce this to a test > case if needed): Well I just read the dev policy and saw that this was required, so test case attached. It'll break if llvm starts emitting the lsl r0, r0, #3 / asr r0, r0, #1 variants f...

Hi, Currently llvm can generate an invalid sbfx/ubfx op, for instance when compiling encoder/analyse.c in x264 (I'll reduce this to a test case if needed): clang -O3 -Wall -I. -isysroot=/Developer/Platforms/iPhoneOS.platform/ Developer/SDKs/iPhoneOS3.0.sdk -Qunused-arguments -mno-thumb -mdynamic- no-pic -arch armv7 -mcpu=cortex-a8 -mfpu=n...

...<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 > > sequence after this canonicalisation: > test: > .fnstart > @ BB#0: @ %entry > ubfx r0, r0, #1, #15 > add r0, r0, r0 > bx lr > > But when I tried to expand the condition to this c...

...c = and i32 %v, 65535 %d = lshr i32 %c, 1 %e = add i32 %b, %d ret i32 %e } 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 sequence after this canonicalisation: test: .fnstart @ BB#0: @ %entry ubfx r0, r0, #1, #15 add r0, r0, r0 bx lr But when I tried to expand the condition to this case, there are lots of various regression fails. The expan...

...16386 movw r12, #65534 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:...

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

Hi Mats, It's private backend. I will try describing what I am dealing with. struct S { unsigned int a : 8; unsigned int b : 8; unsigned int c : 8; unsigned int d : 8; unsigned int e; } We want to read S->b for example. The size of struct S is 64 bits, and seems LLVM treats it as i64. Below is the IR corresponding to S->b, IIRC. %0 = load

Hi all, It’s been two weeks since I sent the last merge progress email, so here is an update. TL;DR: Almost done! Tim is considering suggesting making the final switchover sometime next week. This would be the final push, where AArch64 gets deleted and ARM64 gets renamed to AArch64, and would signal the end of the merge process. If any of you know of any reason why these two loving