similar to: [LLVMdev] RegisterScavenging on targets without subregisters

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.

Scott Michel skrev: > 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)? You beat me to it :). A simple bypass (patch attached) does at

Kalle: Your patch is similar to what I'd coded (and am testing, which means a couple of hours before I consider committing). Other than cosmetic changes and changing 'NULL' to '0' (it's an integer list, after all). This patch now causes new problems in the CellSPU backend (more stqd's and lqd's), so I have to investigate those before committing the patch.

On Feb 28, 2010, at 11:49 PM, <Kalle.Raiskila at nokia.com> <Kalle.Raiskila at nokia.com> wrote: > Jakob Stoklund Olesen skrev: >> On Feb 26, 2010, at 10:09 AM, Scott Michel wrote: >>> This patch now causes new problems in the CellSPU >>> backend (more stqd's and lqd's), so I have to investigate those >>> before committing the patch. >

I just changed the default register allocator for -O0 builds to the fast allocator. This means that the local register allocator is not used anymore, and since it does more or less the same as the fast allocator, there is no reason to keep it around. I am going to delete it in a week or two. If you are using the local register allocator, please try switching to the fast allocator and report any

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:

On Thu, 2010-06-03 at 02:53 +0200, Jakob Stoklund Olesen wrote: > If you are using the local register allocator, please try switching to the fast allocator and report any bugs you find. > Tried it, and it seems to break quite a big chunk of our tests on SPU :) Before r103488 ("Mostly rewrite RegAllocFast") there was no problem. But with r103488, I get a:

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

The documentation of as.data.frame is not explicit about how it generates column names for the simple vector case, but it seems to use the character form of the quoted argument, e.g. names(as.data.frame(1:3)) [1] "1:3" But there is a strange case: names(as.data.frame(c("a"))) [1] "if (stringsAsFactors) factor(x) else x" I feel fairly comfortable calling this a

Hi! I started writing a LLVM backend for a custom architecture. I have some register and instruction .td files and some other files/classes like a MCStreamer for assembler output. At the moment I can compile some empty programs so far. I implemented the method ::eliminateFrameIndex() similar to the Sparc and ARM backend. The method looks like this: // frame pointer is in reg of class

Hi, I'm new to LLVM. I'd like to know if there is a method I can call whenever I need any available CPU register. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181222/e916b214/attachment.html>

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

Thanks to J.P. I now have a better understanding of how scp really works. I haven't uncovered any dark secrets, or unintended capabilities, I just prevented scp from sending the proper commands via ssh to the remote server. In essence, I gave scp a lobotomy or short-circuit. Either way, it's useful and gives me the desired effect. I don't know if anyone else would find this

Is it possible to get a virtual register and then use that to create a real register? I've seen it done in unittests/CodeGen/MachineInstrTest.cpp like this: unsigned VirtualDef1 = -42; VD1VU->addOperand(*MF, MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true)); But when I do that in my code I get an assertion so I wasn't sure if it's legal or not. Thanks.

My name is Isaac. I'm a student at Cal Poly State University, San Luis Obispo, and I'm currently finishing my thesis on target-specific code optimization for my master's degree. I was wondering if I could ask a few questions I have about working with the LLVM codebase. My thesis involves optimizing the way that LLVM deals with memory operations when targeting the ARM processor

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

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,

Hello llvm'ers, We are using the llvm compiler tools (llvm-link, llc, etc) to generate code for ARM for the Android NDK. We're on a pretty tight deadline and have a host of issues that we could use some help overcoming. We're interested in bringing on a contractor experienced in llvm to help us. Broadly, llc is giving various assertion failures while generating the native code