search for: machineinstrbuild

I just finished coding up a change to how code generation builds machine instructions. The change is in include/llvm/CodeGen/MachineInstrBuilder.h, where when you want to add a register, you have to specify a long list of booleans indicating if it's defined, implicit, killed, dead, or early clobbered. I don't know about you, but it was hard for me to read the source and understand what was going on without looking at the header fi...

Hi Bill, I am using the following version of BuildMI : MachineInstrBuilder BuildMI(MachineFunction &MF, const TargetInstrDesc &TID, unsigned DestReg) I do the following : void createInstrs(std::vector<MachineInstr *>& ilist) { Machine Instr *mi; mi = BuildMI(MF, someTID, so...

...perand(); MachineInstr *RMI = &*UI; ++UI; MachineBasicBlock *RMBB = RMI->getParent(); if (RMBB == MBB) continue; const TargetRegisterClass* RC = mri_->getRegClass(Reg); unsigned NewVReg = mri_->createVirtualRegister(RC); MachineInstrBuilder MIB = BuildMI(*RMBB, RMI, RMI->getDebugLoc(), tii_->get(TargetInstrInfo::IMPLICIT_DEF), NewVReg); (*MIB).getOperand(0).setIsUndef(); RMO.setReg(NewVReg); RMO.setIsUndef(); RMO.setIsKill(); } Souldn't there be a call to v...

...anders at apple.com> Date: Wednesday, January 30, 2019 at 9:32 PM To: "Arsenault, Matthew" <Matthew.Arsenault at amd.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] MachineIRBuilder API Hi Matt, Personally, I like that it follows the same pattern as MachineInstrBuilder used elsewhere in MIR. It would certainly be nice to create whole expressions at once though. I believe that nested SelectionDAG-style get*() functions have an ordering problem when used for MIR that wasn't a problem for SelectionDAG due to the difference in underlying representation. The DA...

...5b in llvm::BuildMI (BB=@0x4b69378, > I={<std::iterator<std::bidirectional_iterator_tag, llvm::MachineInstr, > long int, llvm::MachineInstr*, llvm::MachineInstr&>> = {<No data > fields>}, NodePtr = 0x4b69440}, DL={LineCol = 0, ScopeIdx = 0}, > TID=@0x803a78940) at MachineInstrBuilder.h:183 > #3 0x0000000803451825 in llvm::X86RegisterInfo::emitPrologue > (this=0x1a96220, MF=@0x30eb000) at > /tmp/llvm-svn/llvm/lib/Target/X86/X86RegisterInfo.cpp:1037 > #4 0x0000000802cdf3e5 in llvm::PEI::insertPrologEpilogCode > (this=0x3231900, Fn=@0x30eb000) at > /tmp/llvm-...

...0x00000008028ea45b in llvm::BuildMI (BB=@0x4b69378, I={<std::iterator<std::bidirectional_iterator_tag, llvm::MachineInstr, long int, llvm::MachineInstr*, llvm::MachineInstr&>> = {<No data fields>}, NodePtr = 0x4b69440}, DL={LineCol = 0, ScopeIdx = 0}, TID=@0x803a78940) at MachineInstrBuilder.h:183 #3 0x0000000803451825 in llvm::X86RegisterInfo::emitPrologue (this=0x1a96220, MF=@0x30eb000) at /tmp/llvm-svn/llvm/lib/Target/X86/X86RegisterInfo.cpp:1037 #4 0x0000000802cdf3e5 in llvm::PEI::insertPrologEpilogCode (this=0x3231900, Fn=@0x30eb000) at /tmp/llvm-svn/llvm/lib/CodeGen/Prolo...

...doesn’t allow you to naturally compose operations by using the return value of a build* function to another. I also find this aspect to be pretty error prone, as I discovered it by accident when the registers I had already created weren’t being used. The current set of build* functions all return MachineInstrBuilder, or effectively the inserted instruction. This seems reasonable for some odd low level cases where you are building an instruction that won’t be inserted yet, or you don’t know the operands ahead of time. For the majority of code, I don’t see how this is useful. Most places should be using a buil...

...; namespace RegState { > enum { > Define = 0x1, > Implicit = 0x2, > Kill = 0x4, > Dead = 0x8, > EarlyClobber = 0x10, > ImplicitDefine = Implicit | Define, > ImplicitKill = Implicit | Kill > }; > } [...] > MachineInstrBuilder &addReg(unsigned RegNo, unsigned flags = 0, > unsigned SubReg = 0) const { Hi Bill, I definitely like this change. The staccato bool arguments are impossible to read. One comment: If I forget to update an addReg(Reg, true) call, it will still compile and...

...tr *RMI = &*UI; > ++UI; > MachineBasicBlock *RMBB = RMI->getParent(); > if (RMBB == MBB) > continue; > const TargetRegisterClass* RC = mri_->getRegClass(Reg); > unsigned NewVReg = mri_->createVirtualRegister(RC); > MachineInstrBuilder MIB = > BuildMI(*RMBB, RMI, RMI->getDebugLoc(), > tii_->get(TargetInstrInfo::IMPLICIT_DEF), NewVReg); > (*MIB).getOperand(0).setIsUndef(); > RMO.setReg(NewVReg); > RMO.setIsUndef(); > RMO.setIsKill(); > } > &...

Why do these two guys take a pointer to the basic block, whereas all other BuildMI functions take a reference? They are not checking for null or anything and I didn't see any potential declaration conflicts. Am I missing something? Is there a reason for this? inline MachineInstrBuilder BuildMI(MachineBasicBlock *BB, DebugLoc DL, const MCInstrDesc &MCID) { return BuildMI(*BB, BB->end(), DL, MCID); } inline MachineInstrBuilder BuildMI(MachineBasicBlock *BB, Debug...

...gt;> over the >> place... > > Where would you use this? It seems that the only place that would > need it > is in the DAG schedulers, which turn the dags into a machineinstr > stream. > If so, putting it into the scheduler baseclass would make sense. It gets used in MachineInstrBuilder, MachineInstr, MRegisterInfo, and ScheduleDAG. Basically any place where a vreg currently gets passed around by an unsigned needs to accept the pair. In my working copy I've split it out into it's own header file to reduce extraneous includes. > If you do something like this,...

On Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction:

There are 11 BuildMI() functions in MachineInstrBuilder.h including four using the iterator and one using an instruction. But I just don't think that's it. The creation of the new instruction works fine (works fine with OldMI as well) and the new instruction is present in the assembly output. The problem is removing the old instruction correc...

...# <MCOperand Reg:118>> > > ------------------------------------------------------------------------------------------------------- > I'll be honest and say I don't really know how to add the operands > properly to BuildMI. I figured out the following so far > MachineInstrBuilder thing = BuildMI(MachineBB, Position in MBB , > DebugLoc(not sure what this accomplishes), TII->get( X86 instruction I > want), where instruction result goes) > > this has .add(MachineOperand) > .addReg(X86::a reg macro) > .addIMM(a constant like 0x8) &...

...defs for the registers used to pass and return parameters. If you writie a .ll file that makes a call you should be able to see all these components in the generated MIR. > Therefore how can I set the callee function and the arguments of the function? For a direct call, you'd normally use MachineInstrBuilder's addGlobalAddress to set the callee. You have to emit separate moves and stores before the call to put the arguments in the correct registers and stack slots. Be careful not to clobber live registers! We can probably give a few more details (like the call instruction to use, and which regis...

...isn't enough for me to be able to connect the dots. Below I have sample code: %gs holds a base address to a memory location where I am trying to store information. I am trying to update the %gs register pointer location before saving more values, etc. LLVM C++ codeMachine Function pass code: MachineInstrBuilder sss = BuildMI(MBB, MBB.begin(), DL, TII->get(X86::SUB32ri),X86::GS) .addReg(X86::GS) .addImm(0x8); machine function pass dump: %gs = SUB32ri %gs, 8, implicit-def %eflags Objdump -d assembly from executable 400510: 81 ed 04 00 00 00 sub $0...

It looks like you are not using the right overloaded version of function BuildMI defined in MachineInstrBuilder.h. The register operand added to instruction sb should be a use, not a def operand. So this function should be called, BuildMI(BB, dl, TII->get(Mips::SB)).addReg(tmpReg1) instead of BuildMI(BB, dl, TII->get(Mips::SB), tmpReg1) On Sat, Jul 21, 2012 at 11:41 AM, Yang Yang <geraint09...

...uld set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. But I think it would be convenient to add addUse() and addDef() methods to MachineInstrBuilder, instead of requiring the tedious addReg(..., RegState::Define). /jakob

...olds a base address to a memory > >>> location where I am trying to store information. I am trying to update > >>> the %gs register pointer location before saving more values, etc. > >>> > >>> LLVM C++ codeMachine Function pass code: > >>> MachineInstrBuilder sss = BuildMI(MBB, MBB.begin(), DL, > >>> TII->get(X86::SUB32ri),X86::GS) > >>> .addReg(X86::GS) > >>> .addImm(0x8); > >>> > >>> machine function pass dump: > >>> %gs = SUB32ri %gs,...

...g processed. 3.. Add or remove MachineFunctions from the current Module. 4.. Add or remove global variables from the current Module. 5.. Maintain state across invocations of runOnMachineFunction (including global data) It seems I cannot insert some instructions, right? For MachineInstr.h and MachineInstrBuilder.h and X86InstrBuilder.h, I am just wondering if we can construct some X86 assemble instruction? if so, can we insert the X86 assemble instruction to bytecode( bytecode is IR code which should be conflicted with X86 asm) if I used runOnMachineFunction pass ?