similar to: [LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?

Tom, My current example is a global address; however, it could be any operand in theory. The arch allows for direct mem op support for ex instructions, so it could be any type of address or any type of imm or any type of register. For example, we are using intrinsics for some instructions since LLVM does not support them. Table gen does not allow for matching to direct mem op because the

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for

I'm not sure I understand what your problem is, but are you calling the removeRegOperandFromUseList on the machine operand after changing it to GA? You have to call removeRegOperandFromUseList before changing the operand's type, as it expects a register operand. 2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > @Alex: Thanks. setOffset(0) eliminated any previous

Fernando, The code there should be more or less functional, though it's not currently used by anything. Eventually it should probably be moved to a method on MachineBasicBlock. The API breakage you're seeing is because some methods moved around. Feel free to fix it. :-) --Owen On Jan 26, 2008, at 6:31 PM, Fernando Magno Quintao Pereira wrote: > > Hi LLVMers, > >

Hi LLVMers, what is the status of breaking critical edges in machine functions? I just compiled the top of the LLVM tree, and I found llvm/CodeGen/BreakCriticalMachineEdge.h. But this file seems not to be up-to-date with the other classes in the top of the tree. For instance, it calls isTerminatorInstr on llvm::TargetInstrInfo, but this method is no longer there. If I want to break

Hi, I think I've found a bug in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg,

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.

The docs for the above-mentioned function say: This method may modify or replace the specified instruction, as long as it keeps the iterator pointing the the finished product. What does it mean to "keep an interator". Was "invalidates the iterator" intended, so something else. Another question, is how do I really replace the instruction. The operator= is private

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug in this method. > > I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > >

So, an update. I have managed to generate comments, although it does create a non-existent instruction. My method is as follows (and I would appreciate any comments on how to do it "better", although note that this won't make it into the final code :).) 1. I declared a "fake" instruction type to hold comments, ala: class FakeInst<dag outs, dag ins, string asmstr,

Is there any way to determine if a Register-type MachineOperand represents a fixed machine register? For example, call arguments must end up in specific machine register but I don't see any way to ascertain this from the information in MachineOperand. Basically, I need to know if I am allowed to rename a MachineOperand or not after register allocation. Thanks!

You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent information, from

This only has the register class information, not the register type information. My register class has multiple register types and I need to know how to differentiate which register type of my register class of the current register. The information in the MVT data type is what I need, i.e. the position in the GPRVT array of each register. Something equivalent to MVT getValueType() but for

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

Hello, I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const

How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596

On May 16, 2013, at 2:23 PM, dag at cray.com wrote: > Is there any way to determine if a Register-type MachineOperand > represents a fixed machine register? For example, call arguments must > end up in specific machine register but I don't see any way to ascertain > this from the information in MachineOperand. Basically, I need to know > if I am allowed to rename a

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general

Dear all, I am looking to output assembly comments in my emitPrologue() function, just for my own readability. Searching for a way to do this found me this thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043722.html, which says that the best way to output comments from somewhere like emitPrologue() is to: 1. Create an MDString for the comment. 2. Attach it to an LLVM

On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote: > I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering if there is a specific reason on limiting the size of the flags to 8 bits. We create *LOTS* of MachineOperand instances, so it needs to be as small as possible. > Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally