search for: machineinsts

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

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 instruction flows? The

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 correctly. > The loop header needs to be

I made the change to the BuildMI() call. Again, I don't think that matters. #define BUILD_INS(opcode, new_reg, i) \ 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();

This seems a very natural approach but I probably am having a trouble with the iterator invalidation. However, looking at other peephole optimizers passes, I couldn't see how to do this: #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for

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

Hello, I recently found that LLVM generates sub-optimal assembly for a tail call optimization case. Below is an example (https://godbolt.org/z/ao15xE): > void g1(); > void g2(); > void f(bool v) { > if (v) { > g1(); > } else { > g2(); > } > } > The assembly generated is as follow: > f(bool): # @f(bool) > testb %dil, %dil > je .LBB0_2 >

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 >

On Tue, Mar 6, 2018 at 5:55 AM, Andrew Trick via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > > On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at

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,

> On Mar 6, 2018, at 4:20 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. > > Personally, I

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

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

Hello All, My name is Prakhar Bansal and I am a graduate student in computer engineering at Iowa State University. In my research work, I have worked on Memory access monitoring of an application using the LLVM static analysis framework, where I developed a tracing tool using an LLVM module pass to perform tracing across multiple functions using call graph analysis and also implemented static

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.

On 24 June 2014 01:55, Philip Reames <listmail at philipreames.com> wrote: > > On 06/19/2014 09:35 AM, Yi Kong wrote: >> >> 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

Hi all, I am using the fast register allocator on a partially allocated machine function. I have noticed reserved registers (i.e. liveins) are marked as free after first use (in usePhysReg(..) method). This seems an error to me as a livein might be still used later in the basic block. As I understand this should check for isKill() before marking it as free, but I see it even *sets* the kill

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 get into more detail, I'm trying to update WebAssembly's `call` instruction. `call` is currently constrained to return one or zero arguments, so in TableGen we have a separate call Instruction for each possible return type. But I need to update calls to return arbitrarily many values of any combination of WebAssembly types, so even if we imposed some reasonable artificial limit like 8

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