[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