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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
