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

[Michael Liao via Phabricator via llvm-commits]

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; }
+
----------------
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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89447