search for: machineinst

I'm writing a peephole pass and I'm done with the X86_64 instruction level detail work. But I'm having difficulty with the basic block surgery of replacing the old MachineInst. The peephole pass gets called per MachineFunction and then iterates over each MachineBasicBlock and in turn over each MachineInst. When it finds an instruction which should be replaced, it builds a new instruction: NewMI = BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode))...

Is there any way to discover whether a particular operand of a MachineInst participates in addressing? That is, if the MachineInst references memory, can I tell, given an operand, whether that operand is part of the address calculation for the instruction? Also, is there any reasonable way to get the set of machine instructions to which the output(s) of some machine in...

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...

...\ BuildMI(*MBB, OldMI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) I didn't completely understand your other proposed change: ​ for (MachineBasicBlock::iterator MBBI = MBB->begin(); MBBI != MBB->end(); ) { MachineInstr *NewMI = NULL; OldMI = MBBI; ++MBBI; I think you're saying with ++MBBI to step past the old instruction. This seems faster speedwise but more of a hack than just restarting the loop. But I'll try it. It implies a certain knowledge of the iterator and MBB. I accidentally touch...

...(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for (MachineFunction::iterator MFI = MF.begin(), MFE = MF.end(); MFI != MFE; ++MFI) { MachineBasicBlock* MBB = MFI; for (MachineBasicBlock::iterator MBBI = MBB->begin(); MBBI != MBB->end(); ++MBBI) { MachineInstr *NewMI = NULL; OldMI = MBBI; // %EFLAGS<imp-def> is getting copied // %RDX<imp-use,kill> is not getting copied (when it appears) switch (OldMI->getOpcode()) { default: continue; // .... case X86::BT64ri8: case X86::B...

On Jan 11, 2008, at 2:00 PM, David Greene wrote: > Is there any way to discover whether a particular operand of a > MachineInst > participates in addressing? That is, if the MachineInst references > memory, > can I tell, given an operand, whether that operand is part of the > address > calculation for the instruction? Nope, not that I know of. > Also, is there any reasonable way to get the set of ma...

...; However, in this specific case (where no function epilogue is needed), one can actually change 'je .LBB0_2' to 'je g2()' directly, thus saving a jump. Is there any way I could instruct LLVM to do this? For my use case, it is acceptable to do this at any level (C++ level /IR level /MachineInst level is all fine). Thanks! Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/400bcc5a/attachment.html>

On Friday 11 January 2008 16:36, Chris Lattner wrote: > On Jan 11, 2008, at 2:00 PM, David Greene wrote: > > Is there any way to discover whether a particular operand of a > > MachineInst > > participates in addressing? That is, if the MachineInst references > > memory, > > can I tell, given an operand, whether that operand is part of the > > address > > calculation for the instruction? > > Nope, not that I know of. Ok. > On mainline, you ca...

...all predicates can be easily rewritten/adapted to work with MCInst and MCschedModel. Predicates can potentially access information which is not normally reachable through the MCSchedModel interface. For example, predicate code coud use the TargetInstrInfo interface to obtain extra description for MachineInst objects. This is what happens for ARM targets, where the `PredicateProlog` casts the TargetInstrInfo object to a ARMBaseInstInfo, and predicated use the ARMBaseInstrInfo interface. Some predicates defined by the cortex-a9 scheduling model select the scheduling class "based on the number of mem...

Hi all, I'm playing with intrinsics and I was wondering how to lower an intrinsic that should return, for example, an int1? More precisely, how to return the value when working with MachineInst? First, I have defined an instrinsic in "Intrinsics.td": _def int_antivm : Intrinsic<[llvm_i1_ty], [], [], "llvm.antivm">;_ Then I want to lower it in the X86 backend, so I defined a pseudo instruction in "X86InstrCompiler.td": _let usesCustomInserter = 1...

...cates can be easily rewritten/adapted to work with MCInst and MCschedModel. > > Predicates can potentially access information which is not normally reachable through the MCSchedModel interface. For example, predicate code coud use the TargetInstrInfo interface to obtain extra description for MachineInst objects. This is what happens for ARM targets, where the `PredicateProlog` casts the TargetInstrInfo object to a ARMBaseInstInfo, and predicated use the ARMBaseInstrInfo interface. > Some predicates defined by the cortex-a9 scheduling model select the scheduling class "based on the number o...

...ther the intention is whether you lower from one to the next. For example, gcc lowers from GENERIC to GIMPLE and never looks back, Open64 lower VHL to HL to ML to LL to VLL the same way. The SCEV format at least isn't like that, but there is at least one lowering step from the IR to the DAG/MachineInsts that machine-specific CodeGen uses. MCInst may not be an IR on the grounds that it's not intermediate, it's just a direct representation of assembly instructions. I want > to be able to get as much information from a front-end as possible. Mainly > I need to find out dependen...

> > Hi Reshabh, and congratulations on being selected for GSoC. I haven't > looked at supporting larger than native-width pointers on a target > before. I'd thought that AVR might be relevant (given it uses 16-bit > pointers but has 8-bit GPRs). See the description here > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>. > Many thanks Alex,

...ultiple functions using call graph analysis and also implemented static instrumentation using LLVM APIs, to finally generate memory accesses trace for a program. For GSOC'20, I am interested in working on either of 2 research projects that are based on llvm, First is encode analysis results in MachineInstr IR, second is finishing the Slimmer Tool to find potential performance bugs in programs. I checked the details of the existing work to learn about the Slimmer tool, but I am looking for more information on requirements, and help with resources on both of these projects. Thank you. Regards, Prakha...

Hello Everyone! New to the forums, so hopefully I'm not a nuisance. I just wanted to know where to go (since I heard there were about 5 different intermediate forms for llvm) to find the highest level intermediate form of llvm. I want to be able to get as much information from a front-end as possible. Mainly I need to find out dependencies and control flows, amongst a few other things.

...uiltin_arm_isb(); >> __schedule_barrier_full(); >> } > > Given your examples are in C, I want to ask a clarification question. Are > you proposing adding such intrinsics to the LLVM IR? Or to some runtime > library? If the later, *specifically* which one? Or at the MachineInst > layer? > > I'm going to run under the assumption you're using C pseudo code for IR. If > this is not the case, the rest of this will be off base. Yes, IR. > I'm not familiar with the exact semantics of an "isb" barrier, but I think > you should look at t...

...operand. I feel this might be because FastRegAlloc is prepared to work on MI code with no proper def/kill markers. Is this behaviour intended? Otherwise should not be complex to fix. BR Carlos PD: in case someone wonders, the reason I can not use one of the other register allocators is that my MachineInst level code is heavily preprocessed and is no longer SSA at this point, which prevents running LiveVariables on it.

Hi, I need to generate a branch instruction from within CodeGenIntrinsic in SparcV9BurgISel.cpp. I generate a few instructions and add them to the mvec vector, and then I need to generate a branch whose target is the first instruction in the vector. I've seen how other portions of the code do this, but they have access to more information than CodeGenIntrinsic. Thanks, Brent

...to placing them in registers. The value stack is not in memory and not addressable, so it is not the same as the normal stack of call frames, which we also have. Instead, the value stack takes the place of registers. The way we model the value stack is by using virtual registers exclusively in the MachineInst layer, then rearranging (i.e. "stackifying") the instructions and removing all registers entirely right before lowering to MC. We skip register allocation entirely, since WebAssembly does not have registers to allocate. We use virtual registers instead of physical registers because the va...

Hi all, I'm currently working on implementing ACLE extensions for ARM. There are some memory barrier intrinsics, i.e.__dsb and __isb that require the compiler not to reorder instructions around their corresponding built-in intrinsics(__builtin_arm_dsb, __builtin_arm_isb), including non-memory-access instructions.[1] This is currently not possible. It is sometimes useful to prevent the