This is an archive of the discontinued LLVM Phabricator instance.

[HLSL] add pow library function
ClosedPublic

Authored by bob80905 on Jul 24 2023, 3:39 PM.

Details

Summary

This change exposes the pow library function for HLSL, only available for floating point types.
The pow function is supported for all scalar, vector, and matrix types that contain floating point types.

The full documentation of the HLSL pow function is available here:
https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow

Diff Detail

Event Timeline

bob80905 created this revision.Jul 24 2023, 3:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 3:39 PM
Herald added a subscriber: Anastasia. · View Herald Transcript
bob80905 requested review of this revision.Jul 24 2023, 3:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 3:39 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
bob80905 updated this revision to Diff 543730.Jul 24 2023, 3:44 PM
  • remove non-floating-point func decls from header file
bob80905 updated this revision to Diff 543731.Jul 24 2023, 3:46 PM
  • add eof newline
beanz added inline comments.Jul 24 2023, 4:20 PM
clang/test/CodeGenHLSL/builtins/pow.hlsl
7

Does this need to set -D__HLSL_ENABLE_16_BIT? If 16-bit types are disabled, this should result in half being 32-bit right?

13

nit: can you clang-format this source?

bob80905 added inline comments.Jul 24 2023, 4:22 PM
clang/test/CodeGenHLSL/builtins/pow.hlsl
7

The define is necessary (the test fails otherwise) because without the definition, the definition of "half4" wouldn't exist (half4 is defined in hlsl_intrinsics.h).
To your second question, yes, I think that's correct.

13

Will do

Looking at https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow, it seems a bit underspecified, but do we need to worry about differences between that spec and IEEE behaviour here? For example, it says there that x<0, y=any -> NaN, but we'll only generate NaN for non-integer y in these cases as per https://en.cppreference.com/w/c/numeric/math/pow

clang/test/CodeGenHLSL/builtins/pow.hlsl
11

Why check the function name in the no-half case but not the other check?

bob80905 updated this revision to Diff 543757.Jul 24 2023, 5:25 PM
  • add func name to checks, clang format
bob80905 added inline comments.Jul 24 2023, 5:28 PM
clang/test/CodeGenHLSL/builtins/pow.hlsl
11

This is the pattern I've been using since starting on the upstreaming effort, so I've been copying this pattern. I don't see a reason why the function name shouldn't be included, so I'll add it here.

Looking at https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow, it seems a bit underspecified, but do we need to worry about differences between that spec and IEEE behaviour here? For example, it says there that x<0, y=any -> NaN, but we'll only generate NaN for non-integer y in these cases as per https://en.cppreference.com/w/c/numeric/math/pow

FWIW it looks like the behaviour here matches what DXC does in practice today, so discussing the discrepancy here probably doesn't need to block getting this in

bogner accepted this revision.Aug 8 2023, 11:19 AM
This revision is now accepted and ready to land.Aug 8 2023, 11:19 AM
bob80905 updated this revision to Diff 548296.Aug 8 2023, 11:34 AM
  • clang format pow.hlsl
This revision was landed with ongoing or failed builds.Aug 8 2023, 1:07 PM
This revision was automatically updated to reflect the committed changes.