[PATCH] D89447: [MachineInstr] Add support for instructions with multiple memory operands.

Michael Liao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 3 07:08:45 PST 2020


hliao marked an inline comment as done.
hliao added inline comments.


================
Comment at: llvm/include/llvm/CodeGen/TargetInstrInfo.h:1733
+  /// in MachineInstr returns conservative result to avoid quadratic overhead.
+  virtual unsigned getMemOperandAACheckLimit() const { return 4; }
+
----------------
dmgreen wrote:
> hliao wrote:
> > Kayjukh wrote:
> > > hliao wrote:
> > > > dmgreen wrote:
> > > > > So the limit on the number of alias checks is effectively 16?
> > > > > 
> > > > > Would it be worth making it so limit is on the total number of checks, not the MemOperands per instruction? That way an instruction with a single operand could be compared to an instruction with many (which I imagine would be a common case).
> > > > Just IMHO, the limit here is more straightforward to figure out. The backend needs to consider the corner case where two instructions with more than one mem operands are checked.
> > > I think it would make sense to still limit the number of checks instead of the number of memory operands. If, say, you put a limit of 16 checks---which would be equivalent to the 4 memory operands you set there----then you can compare both instructions with 4 memory operands each but also an instruction with a single memory operand with another one that happens to have 8.
> > > 
> > > The bound on the cost would be the same but it would make the check more flexible.
> > if a target processor has a native instruction with up to 8 mem operands, won't the developer set this limit to 8 instead of 4 to support all combinations of possible native instructions? My point is that should such a limit be mainly decided by the target processor or possible memory operands due to post-RA optimizations, which one is more reasonable?
> I would make it a total limit. Consider the arm backend where we can have 16 MMO's in a single ldm instruction (sort of). You do not want to put the limit here to 16 per instruction, as that would put the total limit to 256! Far too high! Even a limit of 8 per instruction would sound very high.
> 
> But if the limit was a total of 16 then at least the ldm with 16 operand could be compared against an instruction with 1. And a ldm with 8 operands could be compared against a ldrd with 2.
I see your point. That's reasonable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89447/new/

https://reviews.llvm.org/D89447



More information about the llvm-commits mailing list