search for: pregs

...w how > to get the appropriate TargetRegisterClass (needed to call > CreateSpillStackObject). Should I instead be generating code to save > register EBP at the start of scinstal, restoring it at the end of that > function? > > Susan > > > > ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); > for (int i = 0; i < pregs.size(); ++i) { > if (MRI->isReserved(pregs[i])) > continue; > // use preg... > } > > You could also use the AllocationOrder class to simplify the task of > finding valid pregs, though it doe...

...llocated to any vreg in function bar. Loading/saving RBP should be managed by the stack frame setup/teardown code. If it doesn't already, your allocator should filter out reserved registers (See MachineRegisterInfo::isReserved(unsigned preg)) when assigning physregs. ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); for (int i = 0; i < pregs.size(); ++i) { if (MRI->isReserved(pregs[i])) continue; // use preg... } You could also use the AllocationOrder class to simplify the task of finding valid pregs, though it does require you to use VirtRegMap. If you...

Doug, I have been attempting to learn a little bit about nlme without too much documentation except the online help. The Latex file in the nlme directory looks interesting but uses packages that I do not have so that I have not been able to read it. I have run the example from gnls to compare it with the results I get from my libraries (code below - I have not included output as it is rather

...priate TargetRegisterClass > (needed to call CreateSpillStackObject). Should I instead be > generating code to save register EBP at the start of scinstal, > restoring it at the end of that function? > > Susan > > >> >> ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); >> for (int i = 0; i < pregs.size(); ++i) { >> if (MRI->isReserved(pregs[i])) >> continue; >> // use preg... >> } >> >> You could also use the AllocationOrder class to simplify...

...ral general purpose registers for computation. If there is an instruction which uses parameters, I should first use a move instruction, which moves the value to general purpose register. For example, in RegisterInfo.td , I have following register classes: // this is for storing parameters only def PRegs : RegisterClass<"FOO", [i32], 32, (add P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, P10, P11, P12, P13, P14, P15)>; // this is general purpose register class def GRRegs : RegisterClass<"FOO", [i32], 32, (add R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10)>; // this is...

Thanks Lang, I'll try substPhysReg. I did try your latest code, and although it made the assembler errors go away, now some of my tests produce bad output when executed. I need to look into that some more... (I did change my "usedPregSet" to be ALL pregs used in the whole function, not just those in the current instruction, so the problem should not be the erroneous over-writing of a live preg.) Also, I'm confused about the code that gets a preg for a given vreg. Previously,you gave me code that takes into account t...

Thanks Jakob. I should have mentioned that earlier. :) When you see mismatched sizes on operands it's a fair bet that the subreg rewriting has gone wrong. I should have pulled that entirely out of the preg search loop in the previous example. Fixed version attached. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Susan, Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg operand, taking the subregister index into account. That is what my examples have been doing manually. Using substPhysReg would allow you to tidy the Gcra code up slightly. - Lang. On Thu, Nov 15, 2012 at 11:21 AM, Lang

...opy between >> these registers. The copy simultaneously must have a REX prefix, and cannot >> have a REX prefix, hence the assertion. >> >> The problem is that not all registers in a class are allocable for all >> vregs. As you can see from the above constraint, which pregs are valid >> varies dynamically depending on the context that the register is used. The >> trick is to query the "allocation order" for a class (and as an added >> headache filter out any reserved registers). I've attached a test-case >> where I do this somewha...

...case contains > a copy between these registers. The copy simultaneously must have a > REX prefix, and cannot have a REX prefix, hence the assertion. > > The problem is that not all registers in a class are allocable for all > vregs. As you can see from the above constraint, which pregs are valid > varies dynamically depending on the context that the register is used. > The trick is to query the "allocation order" for a class (and as an > added headache filter out any reserved registers). I've attached a > test-case where I do this somewhat manually....

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

...%vreg15 to AH, and the test case contains a copy between these registers. The copy simultaneously must have a REX prefix, and cannot have a REX prefix, hence the assertion. The problem is that not all registers in a class are allocable for all vregs. As you can see from the above constraint, which pregs are valid varies dynamically depending on the context that the register is used. The trick is to query the "allocation order" for a class (and as an added headache filter out any reserved registers). I've attached a test-case where I do this somewhat manually. In short: int regClass...

...y must have a REX prefix, >>> and cannot have a REX prefix, hence the assertion. >>> >>> The problem is that not all registers in a class are >>> allocable for all vregs. As you can see from the above >>> constraint, which pregs are valid varies dynamically >>> depending on the context that the register is used. The trick >>> is to query the "allocation order" for a class (and as an >>> added headache filter out any reserved registers). I've >>>...

...>> The copy simultaneously must have a REX prefix, and cannot have a >> REX prefix, hence the assertion. >> >> The problem is that not all registers in a class are allocable >> for all vregs. As you can see from the above constraint, which >> pregs are valid varies dynamically depending on the context that >> the register is used. The trick is to query the "allocation >> order" for a class (and as an added headache filter out any >> reserved registers). I've attached a test-case where I do this >...

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code to change virtual registers to physical registers

...st case contains a copy between > these registers. The copy simultaneously must have a REX prefix, and cannot > have a REX prefix, hence the assertion. > > The problem is that not all registers in a class are allocable for all > vregs. As you can see from the above constraint, which pregs are valid > varies dynamically depending on the context that the register is used. The > trick is to query the "allocation order" for a class (and as an added > headache filter out any reserved registers). I've attached a test-case > where I do this somewhat manually. In s...

Hi Susan, The problem now is the usedPregSet. Take the instruction: %vreg13:sub_32bit<def> = ADD32rr %vreg13:sub_32bit, %EAX<kill>, %EFLAGS<imp-def,dead> %EAX will be added to usedPregSet when the instruction is encountered, but %vreg13 is a different class (64bit registers), so none of its candidates will conflict. In a...

Thanks Lang! Here's another question: I'm trying to process this input: int main() { return 0; } but I'm getting an error Assertion `!Fn.getRegInfo().getNumVirtRegs() && "Regalloc must assign all vregs"' failed. At the start of runOnMachineFunction I call Fn.getRegInfo().getNumVirtRegs(); and find that there is 1 virtual register. However,

Estimados ?podrían enviarme un ejemplo en el que analicen un documento de texto con la librería library(tm) mis saludos cordiales jose [[alternative HTML version deleted]]

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()