similar to: [LLVMdev] Loads/Stores and MachineMemOperand

On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. > > But what is the guarantee/constraint placed on

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is

On Dec 11, 2012, at 11:00 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. The MMOs provide extra,

Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? On Wed, Dec 12, 2012 at 9:50 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Dec 12, 2012, at 5:50 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > Is this documented somewhere?

On Dec 13, 2012, at 4:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is there a reason MachineMemOperands are not guaranteed to be persisted in late optimization passes? Is there a use-case where they should be stripped? That's not really the issue, though. As an intermediate representation, MI should be reasonably self-contained. The MMOs are pointers into an

Is this documented somewhere? On Wed, Dec 12, 2012 at 6:54 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Dec 11, 2012, at 11:00 AM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > > I want to get some clarification on the exact semantics of the > MachineMemOperand attached to memory-touching instructions. From what I >

On 9/27/19 7:33 AM, Matt Arsenault via llvm-dev wrote: > > >> On Sep 27, 2019, at 09:07, Björn Pettersson A via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Obviously we do not store into two locations (it is still a single >> two byte store). >> So is it (always) correct to interpret the list of

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

Looking through the X86 GlobalISEL code for selecting loads and stores, I'm not seeing the creation of the MachineMemOperands I'd expect to see and do see being generated by SelectionDAG.  Is this simply an oversight, or is there some aspect of the new design which pushes us away from MMOs? Various parts of the machine instruction level optimization passes use the existence and

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1.s1:

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

Hi Duncan, No, it hasn't been reviewed yet. On Mon, May 13, 2013 at 8:50 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, did anything happen with this patch? > > Ciao, Duncan. > > > On 09/05/13 04:04, Akira Hatanaka wrote: > >> The following code snippet taken from StackColoring::**remapInstructions >> clears a >> mem operand if it

On Feb 11, 2010, at 12:07 PM, David Greene wrote: > On Thursday 11 February 2010 14:02:13 Dan Gohman wrote: > >>>> Putting a bit (or multiple bits) in MachineMemOperand for this >>>> would also make sense. >>> >>> Is there any chance a MachineMemOperand will be shared by multiple >>> instructions? >> >> Yes. > > Then

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

On Dec 12, 2012, at 5:50 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is this documented somewhere? It seems that it isn't. It ought to go in the header file. /jakob

I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get

Thanks for the details! How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn't have MachineMemOperands? I'm seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement,