[PATCH] D71698: [AArch64][SVE] Add intrinsic for non-faulting loads

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 8 12:41:50 PST 2020


efriedma added inline comments.


================
Comment at: llvm/lib/Target/AArch64/SVEInstrFormats.td:5333
+  // We need a layer of indirection because early machine code passes balk at
+  // physical register (i.e. FFR) uses that have no previous definition.
+  let hasSideEffects = 1, hasNoSchedulingInfo = 1, mayLoad = 1 in {
----------------
sdesmalen wrote:
> efriedma wrote:
> > kmclaughlin wrote:
> > > efriedma wrote:
> > > > This is depending on hasSideEffects to preserve the correct ordering with instructions that read/write FFR?  That probably works.  I guess the alternative is to insert an IMPLICIT_DEF of FFR in the entry block of each function.
> > > > 
> > > > What are the calling convention rules for FFR?  Is it callee-save?  If not, we might need to do some work to make FFR reads/writes do something sane across calls inserted by the compiler.
> > > The FFR is not callee-saved. We will need to add support to save & restore it where appropriate at the point the compiler starts generating reads to the FFR, but for the purpose of the ACLE the user will be required to do this if necessary.
> > How can the user write correct code to save/restore the FFR?  The compiler can move arbitrary readnone/argmemonly calls between the definition and the use.
> There are separate intrinsics for loading/writing the FFR (svrdffr, svsetffr, svwrffr), which use a `svbool_t` to keep the value of the FFR. These intrinsics are implemented in the same way with a Pseudo with `hasSideEffects = 1` set.
> 
> I thought this flag would prevent other calls from being scheduled/moved over these intrinsics, as they have unknown/unmodelled side-effects and would thus act kind of like a barrier?
> 
The issue would be transforms at the IR/SelectionDAG level. We can probably model calls at the MIR level correctly, like you're describing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71698





More information about the llvm-commits mailing list