search for: isknownneverinfin

On Mon, Sep 14, 2020 at 12:45 PM Sanjay Patel <spatel at rotateright.com> wrote: > Yes, that looks like a bug. The transform is ok in general for negative > numbers, but -Inf is a special-case for pow(), right? > If so, we probably need an extra check of the input with > "isKnownNeverInfinity()". > There is an extra check there already, but it uses "select" instead of branching. One question is if branching is okay to use instead. Or perhaps you mean the transform should not be done unless "isKnownNeverInfinity()" returns true. > If there are other er...

...<spatel at rotateright.com> >> wrote: >> >>> Yes, that looks like a bug. The transform is ok in general for negative >>> numbers, but -Inf is a special-case for pow(), right? >>> If so, we probably need an extra check of the input with >>> "isKnownNeverInfinity()". >>> >> There is an extra check there already, but it uses "select" instead of >> branching. One question is if branching is okay to use instead. Or perhaps >> you mean the transform should not be done unless "isKnownNeverInfinity()" >&gt...

The transformation in LibCallSimplifier::replacePowWithSqrt with respect to -Inf uses a select instruction, which based on the observed behaviour, incorporates the side effects of the unchosen branch. This means that (for pow) a call to sqrt(-Inf) is materialized. Such a call is specified as having a domain error (C17 subclause 7.12.7.5) since the operand is less than zero. Contrast this with