[code-reflection] RFR: [hat] Proposal for bfloat16 [v2]
Juan Fumero
jfumero at openjdk.org
Wed Dec 3 13:47:22 UTC 2025
On Wed, 3 Dec 2025 12:22:47 GMT, Gary Frost <gfrost at openjdk.org> wrote:
>> Juan Fumero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>>
>> - [hat] abstracting the OpenCL and CUDA code builders
>> - Merge branch 'code-reflection' into hat/type/bfloat16
>> - Merge branch 'code-reflection' into hat/type/bfloat16
>> - [hat] remove custom Op for bfloat
>> - single line imports in hat code builders
>> - single line imports in hat code builders
>> - [hat] test matmul with bfloat16
>> - [hat] dialect for bfloat16 removed
>> - [hat] new test file included in the hat test list
>> - [hat] OpenCL handler for bfloat16 via float convs
>> - ... and 12 more: https://git.openjdk.org/babylon/compare/0a7929cc...ddc932c3
>
> hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java line 316:
>
>> 314: byte f32Mixed = hatF16BinaryOp.getF32();
>> 315:
>> 316: oparen();
>
> you might consider leaning into paren($->$.generateReduceFloat....().) rather than balancing parenthesis yourself.
Indeed. Thanks.
> hat/backends/ffi/cuda/src/main/java/hat/backend/ffi/CudaHATKernelBuilder.java line 334:
>
>> 332:
>> 333: if (f32Mixed == HATF16BinaryOp.LAST_OP) {
>> 334: cparen();
>
> Looks like separate executaionpaths here can create imbalanced paren?
The `generateReducedFloatConversionToFloat` already inserts an open parenthesis. I moved it out to make it explicit and avoid confusion.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585175487
PR Review Comment: https://git.openjdk.org/babylon/pull/716#discussion_r2585177940
More information about the babylon-dev
mailing list