sdesmalen 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 {
----------------
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?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71698/new/
https://reviews.llvm.org/D71698
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
