similar to: Strange Machineinstr

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

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,

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

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] > ldr r6, [r4, r6, lsl #2] > bx r6 For the code to execute correctly, either the _ldr_ should be a _ldrne_ instruction or the _ldreq_ instruction should be removed. The error seems 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;

Hi all, I have a question regarding the latency of the true dependency of a store followed by an aliased load in ScheduleDAGInstrs. The latency seems to depend on the store and load being volatile or not as can be seen in the post-RA-sched debug output of the attached ARM example: $ llc -O3 -debug-only=post-RA-sched store_load_latency_test.ll ... SU(2): STRi12 %R2<kill>,

Hi, I am experimenting with creating instructions that write into virtual registers that use the ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) ==

On 7/23/14, 1:20 PM, Tim Northover wrote: [...] > You should probably be specifying a triple directly, and making it an > AAPCS-VFP one for good measure: "armv7-linux-gnueabihf" for example, > or "thumbv7-none-eabihf". You shouldn't even need to set FloatABI for > those two. How do I do this? (I can't find any examples, and the API is decidedly unclear...)

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

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

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'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 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

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

> 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 Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > 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

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 &&