similar to: {ARM} IfConversion does not detect BX instruction as a branch

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]

Hi, guys I am interesting about how to get the switch case value form the Machine Instruction. I know the switch will be converted to jump-table in the Machine Instruction. And in the phase CodeGen , the case-value of SwitchInst can get esasly. but it seems no case -value in Machine Instruction. The MI as follows: Frame Objects: fi#0: size=1, align=0, at location [SP] fi#1: size=4,

Some glitch in the emailer? I have received this message 3 times in a row!? I think that by the time it gets as far as MI-level there is no reversible method of determining the 'case' label at all. The reason I say this, is that I have often seen optimisations that coalesce groups of values into interesting logical tests and jump-tables are completely avoided. For example, a simple

Thanks for your help. Is there possible I can get the realily case value form the MI? For the case in https://bugs.llvm.org/show_bug.cgi?id=34902. as follows. ############################# * GCC v7.1 generated assembly ############################# ** Options: -Os -marm -march=armv7-a foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 sub

Hi, guys I am interesting about how to get the switch case value form the Machine Instruction. I know the switch will be converted to jump-table in the Machine Instruction. And in the phase CodeGen , the case-value of SwitchInst can get esasly. but it seems no case -value in Machine Instruction. The MI as follows: Frame Objects: fi#0: size=1, align=0, at location [SP] fi#1: size=4,

My home e--mail is down, which is where I get my llvm feeds, so please copy any replies to this address as well as the list. The call instruction can define implicit defs. What are the semantics when the call includes a use with a kill of some register and also an implicit def of that register? Is the register to be considered live out at that point? I've found a failing testcase where

Hi I write a machinefunction pass to print all the machinefunction's machine instructions. My target architecture is ARM. However, I don't understand some part of the machine instructions. Below is some of the assembly language for function A. .text:0001C034 STMFD SP!, {R4,R10,R11,LR} > .text:0001C038 ADD R11, SP, #8 > .text:0001C03C

Hi Krzysztof Thank you very much for your quick and clear reply. I know that MIR may not match hardware instructions directly. However, I think the semantics should be similar. For example, the first instruction is a store-multiple instruction in ARM. I think the first four MIR I shown should have the similar semantics with the first three hardware instructions. I still cannot see the

Evan & llvmdev, I'm seeing a case where ARM Load/Store optimizer is breaking code. I have not had any luck trying to come up with a minimal example; it is breaking in our stage 2 LLVM build. But here's what I'm seeing in the debug output: # Before ARMLoadStoreOptimizer: BB#21: derived from LLVM BB %cond.end Live Ins: %LR %R0 %R1 %R7 %R10 %R11 Predecessors according to

I've committed a fix: r149970. Please try it. I would really appreciate it if you can provide us with a test case (unreduced test case is fine). Evan On 2012 2 4, at 09:46, David Meyer <pdox at google.com> wrote: > Evan & llvmdev, > > I'm seeing a case where ARM Load/Store optimizer is breaking code. I have not had any luck trying to come up with a minimal example;

I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: The first three lines and the last two lines alone together are used to compute "sin" for some double number. - line 1: move the stack pointer down 8 - line 2: copy the updated stack pointer to a base register - line 3: copy a

Hi Peng, Can you please open a bugzilla and attache the LL file ? Can you please reproduce it on ToT ? Thanks, Nadav On Feb 7, 2013, at 9:08 PM, Peng Cheng <gm4cheng at gmail.com> wrote: > I have an llvm ir, which generates the following machine code using llc (llvm 3.0 on win32) after # *** IR Dump After X86 DAG->DAG Instruction Selection ***: > > The first three lines

Hi ! I'm trying to modify the code in a machine function pass… I added a new basicblock and I want to add a jump to an another BB from my new BB. Here is my code : bool Obfuscation::runOnMachineFunction(MachineFunction &MF) { MachineBasicBlock *newEntry = MF.CreateMachineBasicBlock(); MF.insert(MF.begin(), newEntry); std::vector<MachineBasicBlock*> origBB;

Hi, I’m facing a crash issue (--target=arm-linux-gnueabi -march=armv8-a+crc -mfloat-abi=hard) and debugging the problem, I found that an intended branch was not taken due to bad code generation after the Post RA Scheduler pass. A CMPri instruction after an INLINEASM block (which inturn contains a cmp, bne instruction) is being moved before the INLINEASM block incorrectly resulting in two

> I expected that this optimization would be picked > up in a cse, gvn, machine-cse or even peepholing pass. > > Comments? At the LLVM IR level this is represented as define i64 @caller() #0 { entry: store i64* @val, i64** @p, align 8, !tbaa !0 store i64 12345123400, i64* @val, align 8, !tbaa !3 %call = tail call i64 @xtr(i64 12345123400) #2 ret i64 %call } Which is

On Aug 2, 2013, at 1:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> I expected that this optimization would be picked >> up in a cse, gvn, machine-cse or even peepholing pass. >> >> Comments? > > > At the LLVM IR level this is represented as > > define i64 @caller() #0 { > entry: > store i64* @val, i64** @p, align 8, !tbaa

I sent a long message yesterday describing a problem I thought had to do with the JIT stubs. After further investigating, the problem seems to be in the code generation. The following basic block seems to have an error in it's code generation: __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i,

In looking at the code in ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is the following condition for not creating tbb-based jump tables: // The instruction should be a tLEApcrel or t2LEApcrelJT; we want // to delete it as well. MachineInstr *LeaMI = PrevI; if ((LeaMI->getOpcode() != ARM::tLEApcrelJT &&

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

Hi Jakob, You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Chad On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org>wrote: > In looking at the code in > ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is > the following condition for not creating