AMDGPU: Handle rounding intrinsic exponents in isKnownIntegral

https://reviews.llvm.org/D158999

AMDGPU: Use pown instead of pow if known integral

https://reviews.llvm.org/D158998

AMDGPU: Use exp2 and log2 intrinsics directly for f16/f32

These codegen correctly but f64 doesn't. This prevents losing fast
math flags on the way to the underlying intrinsic.

https://reviews.llvm.

AMDGPU: Use exp2 and log2 intrinsics directly for f16/f32

These codegen correctly but f64 doesn't. This prevents losing fast
math flags on the way to the underlying intrinsic.

https://reviews.llvm.org/D158997

show more ...

AMDGPU: Handle sitofp and uitofp exponents in fast pow expansion

https://reviews.llvm.org/D158996

AMDGPU: Enable assumptions in AMDGPULibCalls

https://reviews.llvm.org/D159006

AMDGPU: Turn pow libcalls into powr

powr is just pow with the assumption that x >= 0, otherwise nan. This
fires at least 6 times in luxmark

https://reviews.llvm.org/D158908

AMDGPU: Simplify handling of constant vectors in libcalls

Also fixes not handling the partially undef case.

https://reviews.llvm.org/D158905

AMDGPU: Don't require all flags to expand fast powr

This was requiring all fast math flags, which is practically
useless. This wouldn't fire using all the standard OpenCL fast math
flags. This only

AMDGPU: Don't require all flags to expand fast powr

This was requiring all fast math flags, which is practically
useless. This wouldn't fire using all the standard OpenCL fast math
flags. This only needs afn nnan and ninf.

https://reviews.llvm.org/D158904

show more ...

AMDGPU: Cleanup check for integral exponents in pow folds

Also improves undef handling

https://reviews.llvm.org/D159006

AMDGPU: Fix assertion on half typed pow with constant exponents

https://reviews.llvm.org/D158993

AMDGPU: Fix asserting on fast f16 pown

https://reviews.llvm.org/D158903

AMDGPU: Trim dead includes

AMDGPU: Fix verifier error on splatted opencl fmin/fmax and ldexp calls

Apparently the spec has overloads for fmin/fmax and ldexp with one of
the operands as scalar. We need to broadcast the scalars

AMDGPU: Fix verifier error on splatted opencl fmin/fmax and ldexp calls

Apparently the spec has overloads for fmin/fmax and ldexp with one of
the operands as scalar. We need to broadcast the scalars to the vector
type.

https://reviews.llvm.org/D158077

show more ...

AMDGPU: Replace log libcalls with log intrinsics

AMDGPU: Remove special case constant folding of divide

We should probably just swap this out for the fdiv, but that's what
the implementation is anyway.

AMDGPU: Remove special case folding of sqrt

AMDGPU: Remove special case folding of fma/mad

These just get replaced with an intrinsic now. This was also
introducing host dependence on the result since it relied on the
compiler choice to contra

AMDGPU: Remove special case folding of fma/mad

These just get replaced with an intrinsic now. This was also
introducing host dependence on the result since it relied on the
compiler choice to contract or not.

show more ...

AMDGPU: Replace ldexp libcalls with intrinsic

AMDGPU: Replace rounding libcalls with intrinsics

AMDGPU: Replace fabs and copysign libcalls with intrinsics

Preserves flags and metadata like the other cases.

AMDGPU: Replace some libcalls with intrinsics

OpenCL loses fast math information by going through libcall wrappers
around intrinsics.

Do this to preserve call site flags which are lost when inlinin

AMDGPU: Replace some libcalls with intrinsics

OpenCL loses fast math information by going through libcall wrappers
around intrinsics.

Do this to preserve call site flags which are lost when inlining. It's
not safe in general to propagate flags during inline, so avoid dealing
with this by just special casing some of the useful calls.

show more ...

AMDGPU: Try to use private version of sincos if available

The comment was out of date, the device libs build does provide all
the pointer overloads. An extremely pedantic interpretation of the
spec

AMDGPU: Try to use private version of sincos if available

The comment was out of date, the device libs build does provide all
the pointer overloads. An extremely pedantic interpretation of the
spec would suggest only the flat version exists, but the overloads do
exist in the implementation.

https://reviews.llvm.org/D156720

show more ...

AMDGPU: Handle multiple uses when matching sincos

Match how the generic implementation handles this. We now will leave
behind the dead other user for later passes to deal with.

https://reviews.llvm

AMDGPU: Handle multiple uses when matching sincos

Match how the generic implementation handles this. We now will leave
behind the dead other user for later passes to deal with.

https://reviews.llvm.org/D156707

show more ...

AMDGPU: Remove pointless libcall optimization of fma/mad

After the library is linked and trivially inlined, the generic fma and
fmuladd intrinsics already handle these cases, and with precise flag
h

AMDGPU: Remove pointless libcall optimization of fma/mad

After the library is linked and trivially inlined, the generic fma and
fmuladd intrinsics already handle these cases, and with precise flag
handling. This was requiring all fast math flags when we really just
need nsz for the fma(a, b, 0) case.

https://reviews.llvm.org/D156677

show more ...

AMDGPU: Remove pointless libcall recognition of native_{divide|recip}

This was trying to constant fold these calls, and also turn some of
them into a regular fmul/fdiv. There's no point to doing tha

AMDGPU: Remove pointless libcall recognition of native_{divide|recip}

This was trying to constant fold these calls, and also turn some of
them into a regular fmul/fdiv. There's no point to doing that, the
underlying library implementation should be using those in the first
place. Even when the library does use the rcp intrinsics, the backend
handles constant folding of those. This was also only performing the
folds under overly strict fast-evertyhing-is-required conditions.

The one possible plus this gained over linking in the library is if
you were using all fast math flags, it would propagate them to the new
instructions. We could address this in the library by adding more fast
math flags to the native implementations.

The constant fold case also had no test coverage.

https://reviews.llvm.org/D156676

show more ...