[PATCH] D28314: Change sqrt partial inlining to depend on sqrt argument rather than result.

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D28314#637012, @RKSimon wrote:

> In https://reviews.llvm.org/D28314#637005, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D28314#636863, @RKSimon wrote:
> >
> > > Would a TTI isFastMaterializeConstant be enough (similar to what we have in FastISel)?
> >
> >
> > I think this depends on how heuristic we want to make this decision process. There are tradeoffs here with OOO processing, register pressure, etc. We might just want a dedicated TTI interface. This issue with the FP materialization seems just one of many factors. As I understand it, the issue here is giving the x86 processor more time to compute the branch condition (which is difficult to do through the sqrt instruction).
>
>
> Yes avoiding unnecessary sqrtsd is my main interest, but similar issues have been found on other tickets: PR31510 (constant folding complex pow) also attempts the fast path and only then calls the lib func if any of the results are not finite - again testing the inputs may be more sensible.


Can you clarify? The fundamental assumption here is that the non-finite-output case is rare. As such, we're not "avoiding" the  sqrt instruction - we'll almost always need to execute it. Is the problem you're seeing is that the non-finite-output case is not rare, that the rare non-finite-output case is nevertheless expensive enough to worry about, or that testing early is better because of branch-handling effects?


https://reviews.llvm.org/D28314