search for: mo_machineregist

...; real register will be the representative register of the set of > intervals joined together). I understand the representative register could be a physical (real) register if one of the coallescing register is a physical register. But the code _uncondtionally_ changes MachineOperand::optype to MO_MachineRegister, why? (Same question as my previous post) -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>

On Wed, 2005-09-07 at 15:09 +0800, Tzu-Chien Chiu wrote: > I don't understand the following code snippet in LiveIntervalAnalysis.cpp. > > Why changing the type of the opreand from a virtual register to a > machine register? The register number (reg) is still a virtual > register index (>1024). > > > bool LiveIntervals::runOnMachineFunction(MachineFunction &fn)

On 08/09/05, Chris Lattner <sabre at nondot.org> wrote: > This code isn't actually replacing the virtual register with a physreg. Then why changing its optype? It makes the assertion fails: MachineOperand& MO = inst.getOperand(n); if (MRegisterInfo::isVirtualRegister(MO.getReg())) { assert(MachineOperand::MO_VirtualRegister == MO.getType()); ... } Is that alright? Some

>> I am not really sure whether to do a X86NASMPrinter or whether to bypass >> that for now and work on an X86COFFWriter which would be more useful to >> me ? > > I wouldn't suggest writing an X86NASMPrinter: just change the current > Intel printer to do what you want. Noone is currently using the intel > printer, so you can do what you wish to it. Once I

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce