similar to: [LLVMdev] Question About Target Dependent Optimization

On Nov 28, 2010, at 8:29 PM, Isaac Asay wrote: > > I am continuing to look over the code in the ARMLoadStoreOptimizer.cpp file, but I was wondering if you had a specific suggestion or a documentation resource that I could use to perform this instruction rearrangement in an LLVM idiomatic way. Using my algorithm, I already know where I can move MachineInstrs without effecting program

Hi Renato, Thanks for the response. While it is true that creating an IR optimization gives a better return due to it being applicable to any target ASM, there are also a lot of target specific optimizations that devs have felt are worthwhile enough to create, such as the ARMLoadStoreOptimizer.cpp file which contains ARM specific ASM optimizations. So I know that target specific optimizations are

My name is Isaac. I emailed this mailing list a couple years ago because I was working on an ARM specific target optimization for my thesis, and had questions about moving instructions and properly migrating kill flags. I have managed to get that working properly, and I now have a complete optimization that I wish to test. My question is simply this: Is there any established way to inject ARM

On 10 December 2012 03:00, Isaac Asay <iasay at calpoly.edu> wrote: > I've also tried using asm() C calls to force a > specific assembly pattern, but LLVM appears to treat the asm() call like a > single atomic block that does not have the optimizer run on its member > instructions. Hi Isaac, AFAIK, inline assembly is only exported at the end and it's generally kept

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;

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, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

On Wed, Sep 19, 2007 at 05:24:12PM +1000, Emil Mikulic wrote: > http://goanna.cs.rmit.edu.au/~emil/llvm2.1-check-debug.txt Here's an ARM test that cores: $ llvm-as < /home/emil/ll/llvm-2.1/test/CodeGen/ARM/2007-01-19-InfiniteLoop.ll | llc -march=arm -mattr=+v6,+vfp2 Segmentation fault (core dumped) $ gdb `which llc` llc.core [...] (gdb) where #0 0x0853d606 in

Is this the same issue as PR1686? If so, please add to it. What kind of host machine are you using? Thanks, Evan On Sep 19, 2007, at 12:45 AM, Emil Mikulic wrote: > On Wed, Sep 19, 2007 at 05:24:12PM +1000, Emil Mikulic wrote: >> http://goanna.cs.rmit.edu.au/~emil/llvm2.1-check-debug.txt > > Here's an ARM test that cores: > > $ llvm-as <

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

Hello LLVM Community (specifically anyone working with ARM Cortex-M), While trying to compile the Newlib C library I found that Clang10 was generating slightly larger binaries than the libc from the prebuilt gcc-arm-none-eabi toolchain. I looked at a few specific functions (memcpy, strcpy, etc.) and noticed that LLVM does not tend to generate load/store instructions with a register offset (e.g.

Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction. Ops.pop_back(); Ops.pop_back(); // Form the pair instruction. if (isLd) { MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos, dl, TII->get(NewOpc)) .addReg(EvenReg, RegState::Define)

There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that appears to get tripped on targets that don't have subregisters defined: bool SubUsed = false; for (const unsigned *SubRegs = TRI->getSubRegisters(Reg); unsigned SubReg = *SubRegs; ++SubRegs) if (isUsed(SubReg)) { SubUsed = true; break; }

Evan, A test case is extremely hard to pin down. For months now, we've noticed our stage 2 LLVM ARM build has sporadic failures. Tests would start failing, then start working, then start failing, etc, for no apparent reason. The test case I have (llc.bc, which is all of llc in bitcode form, 44.8 MB), only works against r149814. And in this case, there are only 2 cases of the miscompile

Hi All, Given a machine instruction, is it possible to tell which register(s) is still not in use? For example, given one instruction A, if the one follows it (say B) defines register rax, then I can tell rax should spare at instruction A. The purpose is to use the spare register to replace registers used by A, for instrumentation purpose. Regards, Hu Hong -------------- next part

There is also the LivePhysReg facility that I would recomment if you just want to query for a free register and do not need the full feature set of the RegisterScavenger. - Matthias > On Jan 19, 2017, at 5:50 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe what you're after is the register scavenger. > It's in:

I'm not sure exactly what you're after. I was under the impression that you want to know which register is live at a specific point (an instruction). If that's the case, how do one of the two suggested solutions not suffice? If a register is live-in to a block and not killed before your instruction or it has a def and no kill within the block, it is live. Otherwise it is dead and

On Tue, Sep 18, 2007 at 06:41:38PM +1000, Emil Mikulic wrote: > The "make check" produced: > === Summary === > > # of expected passes 2209 > # of unexpected failures 41 > # of expected failures 5 > gmake[1]: *** [check-local] Error 1 > gmake[1]: Leaving directory `/home/emil/ll/objdir-llvm/test' > gmake: ***

Ugh. Management lobotomy kicked in. Need to RTFC better. On Thu, Feb 25, 2010 at 6:18 PM, Scott Michel <scooter.phd at gmail.com> wrote: > There's an assert at line 192, lib/CodeGen/RegisterScavenging.cpp that > appears to get tripped on targets that don't have subregisters defined: > > bool SubUsed = false; > for (const unsigned *SubRegs =

No, I wasn't having a management lobotomy moment. If the target's registers have no subregisters, SubUsed is false and the assert gets tripped. Ok, back to the original question: What was the original intent in this code (lines 186-193 in lib/CodeGen/RegisterScavenging.cpp)? -scooter On Thu, Feb 25, 2010 at 7:00 PM, Scott Michel <scooter.phd at gmail.com> wrote: > Ugh.