[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