search for: mmos

...> only accesses one location. The operands should have been merged in > some way unless the instruction can truly access two distinct addresses I'm a bit less sure of this.  It's on the surface reasonable, but there are some interesting questions. We definitely interpret a list of MMOs as indicating a set of locations which are possibly(?) accessed.  The only piece I'm unsure about is that the existence of an MMO requires the access occurs.  If we do, that raises some interesting consistency questions for cases such as: * Load/Store merging (a superset of the branch fol...

...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, optional information that late optimizers may use to combine or reorder memory operations. In particular, stripping all MMOs does not break the semantics of the program, it just removes some opportunities for optimization. A load or store without an MMO should be treated as if it w...

...mail.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 old version of the program being compiled - The MI representation has undergone many transformations, including CFG changes and code motion. The links provided by the MMOs get more and more sketchy as the program is optimized. Currently, we only use the MMOs for alias analysis...

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?

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 contents of an MMO for optimization legality checks.  As a simple example, we won't fold a load unless we can examine it's MMO to ensure the access is not volatile.  At the moment, this would seem...

Hi All, I've encountered an issue where tail merging MIs is causing a problem with the post-RA MI scheduler dependency analysis and I'm not sure of the best way to address the problem. In my case, the branch folding pass (lib/CodeGen/BranchFolding.cpp) is merging common code from BB#14 and BB#15 into BB#16. It's clear that there are 4 common instructions (marked with an *) in BB#14

In order to implement a subtle memory access optimisation during post-RA scheduling, I want to be able to determine some properties about the memory access. If I have two registers referring to memory, how can I determine if they are derived from the same base-pointer? Often LLVM will optimise to use intermediate registers holding partial displacements, for example, when a 'struct'

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 optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

...> 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, optional information that late optimizers may use > to combine or reorder memory operations. > > In particular, stripping all MMOs does not break the semantics of the > program, it just removes some opportunities for optimization. > > A load or store without an MMO...

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:

...me a counter example > then I'd be hard pressed to disable the optimization in MI and push it > towards the IR level. I'm not sure it is always possible to push these optimizations to the IR level, at least not without adding more Value* ties to instructions (e.g. what we do with MMOs). I have some experience, for example, taking optimizations taking advantage of hardware-counter-based loops and moving into the IR level (so that we can take advantage of ScalarEvolution), and it works to some extent, but is also fairly hacky (the legality-checking part of lib/Target/PowerPC/P...

...nsider, for example, the following situation: 1. We CodeGen a function foo(), and then remove its IR. During this process, we never used an AA query that reached CFL-AA 2. We CodeGen a function bar(), and bar() calls foo(). 3. During (2), we make an AA query on instructions in bar(), which have MMOs with IR Values in bar() 4. CFL-AA is reached and does not have a cached graph for bar(), so it builds one 5. While building the graph for bar(), it reaches the call to foo(), and calls tryInterproceduralAnalysis 6. CFL-AA does not have a cached graph for foo(), so tryInterproceduralAnalysis trig...

...this issue > within LLVM infrastructure, assuming it's possible with the current 'core' > code? Well, I can come up with a bunch of hacks to avoid messing with upstream code =) If you have an answer to the "how do you legalize 8-bit loads?" problem I mentioned (perhaps MMOs provide enough information), then the easiest way would be to just do so in your target. Perhaps a target-specific DAGCombine would work, or marking loads as "Custom". Another solution would be to immediately DAGCombine (again, target-specific code, which IIRC run before target-independ...

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

> On Mar 8, 2016, at 11:50 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > I could attach a patch, but first i’d really like to know if anyone is fundamentally opposed to this. > > > Not necessarily. I think that any information that isn't being serialized in MI right now for a function could be as well. Definitely something for GlobalISel

Regarding the patches, there are two concerns AFAICT: 1. It’s a new instruction and as usual when introducing a new instruction it will require work for some time until most optimizations know about it, and to get rid of any potential perf regression. No big deal; we just need to do the work (and we have already done some of it). 2. The patch was written by a student, which may not have time to

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: