[PATCH] D45576: [RFC] Allow target to handle STRICT floating-point nodes
Ulrich Weigand via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed May 23 10:02:18 PDT 2018
uweigand added a comment.
In https://reviews.llvm.org/D45576#1109697, @hfinkel wrote:
> >> Ah, okay. That doesn't seem so bad. The fact that the number of times they're called can't be observable means, I think, that we only need to model the trapping behavior as writing (and not reading) inaccessible memory. This can't be removed or speculated, but otherwise shouldn't have undo optimization implications.
> >
> > Correction: I mean writing to memory (the trap handler might write memory other than inaccessible memory (e.g., some global variable)). Anything that's escaped (trivially including globals) is fair game.
>
> I suppose that they also get to read memory (so long as they're not using it to keep ordering/count information). So the trap handlers are modeled as reading/writing arbitrary escaped memory. That, plus register dependencies, seems like it should be sufficient.
So if I understand you correctly, you're suggesting (at the MI level) to mark trapping FP operations as mayLoad and mayStore instead of hasSideEffects (as the patch does originally)?
That's probably OK, I think. But this would still restrict the optimization possibilities quite a bit compared to now, so you still wouldn't want to enable it by default in non-strict FP mode, right? In that case we're back to the question whether we need to duplicate all FP patterns or not.
Repository:
rL LLVM
https://reviews.llvm.org/D45576
More information about the llvm-commits
mailing list