[PATCH] D63405: GlobalISel: Don't lose fneg flags when lowering to fsub
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jun 17 09:45:14 PDT 2019
arsenm added a comment.
In D63405#1546410 <https://reviews.llvm.org/D63405#1546410>, @spatel wrote:
> In D63405#1546348 <https://reviews.llvm.org/D63405#1546348>, @arsenm wrote:
>
> > In D63405#1546342 <https://reviews.llvm.org/D63405#1546342>, @spatel wrote:
> >
> > > I'm not familiar with how flags are being used in this layer, but union of flags doesn't match the way we deal with FMF in IR. If the fneg is strict (disregard the irrelevant 'arcp' in that last test), then it's invalid to assume that it inherits the 'nsz' property from its operand.
> >
> >
> > I would expect the lowering here to just preserve the flag on the original instruction, and not propagate the source (as was done here previously). The corresponding expansion in the DAG has a TODO to preserve the flags, so there isn't precedent for this
>
>
> Let me know if I'm not seeing this correctly (haven't looked at MIR very much - it might help if the test was committed with the baseline output first, so we just have a diff in this patch).
> Did we start with 'fneg arcp X' and end up with 'fsub arcp nsz -0.0, X'? Preserving (rather than unioning) the flag should end up with only 'fsub arcp -0.0, X'?
The pre-patch code would fold fneg (fadd flags x, y) -> fsub flags -0.0, (fadd flags x, y), and entirely ignore any flags on fneg. I'm not entirely sure this is correct on its own
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D63405/new/
https://reviews.llvm.org/D63405
More information about the llvm-commits
mailing list