search for: machineintrs

...strs. Also, such a pass will need to work with > virtual registers as you'll need an unlimited supply of temporary > variables. In essence, you'll be undoing register allocation. > > Can you describe why you want to put MachineInstrs into SSA form? I > suspect that putting MachineIntrs back into SSA form is not what you want > to do. > > Regards, > > John Criswell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/c46d4dc3/attachment.html>

Hi, I'm wondering how I can convert "register allocated" code back to SSA form. I realized from MachineRegisterInfo.h that a function leaves SSA form only once and cannot be taken back to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/0124addd/attachment.html>

Can someone explain what MCInst is vs. MachineIntr? I'm porting some patches we have here that affect MachineInstrs and am wondering whether I need to make similar changes in MCInst. Why do we have two machine instruction representations? -Dave

Hi, Recently, I am working on some information collection on the machine instruction (MachineInstr) level. But, sometimes, I need check the corresponding IR level instruction of the a machine instruction. When visiting a machine instruction which is a call (MachineInstr::isCall()), I need to check the arguments of this call site. I know that the CallSite class provides good facility for this

On Jul 9, 2009, at 5:34 PM, David Greene wrote: > Can someone explain what MCInst is vs. MachineIntr? Sure. MCInst is designed to be part of the "MC" set of libraries, which is stuff dealing with machine code. We're building a suite of assemblers and disassemblers out of this. MCInst is integral to this plan. For an assembler you have two pieces: 1. "Recognize"

On Friday 13 November 2009 15:17, you wrote: > > Are these known to be broken right now? I get failure when using either. > > > > $ llc -march=arm -print-machineinstrs hw.bc > > Seems due to David's patches. Ok, it's faulting in SlotTracker with what looks like a bad Function. One of the Argument values is corrupted. I'm not abdicating responsibility, but at

All, I've attached a small patch that adds a new early-clobber operand constraint option to TableGen and would like to get feedback before proceding. As background, the ARM store-exclusive instruction (STREX) stores a success result code in a register operand, and that register cannot be the same register as either the source of the value to be stored, or the base address.

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

Hi James, > On Nov 18, 2015, at 11:53 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Hi Quentin, > > I'm really excited to see this happening! > > My major question is over the testing story for this. How are we going to write unit tests for GIR? Thanks for bringing that up! That is a very good question and also one that will require a lot of work to

What happens when you cascade bitcast? Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? i128 => <16 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0 —

Hi James, I am also confused! > On Jan 12, 2016, at 4:11 PM, Philip Reames <listmail at philipreames.com> wrote: > > I think after reading your link I'm actually more confused. This might just be a wording problem, but let me ask a couple of clarifying questions. > > 1) After compiling the code sequence below (from that page), does the in memory bit pattern differ?