Skip to content

Conversation

@AntonOresten
Copy link
Contributor

No description provided.

Copy link

@giordano giordano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this be done with a pkgextension, without hardcoding the dependency on BFloat16s? Only change which requires some care is the one src/bytecode/types.jl, where you don't add the branch for T === BFloat16, but you can simply define a method julia_to_tile_dtype!(table::TypeTable, ::Type{BFloat16}) in the extension.

@AntonOresten
Copy link
Contributor Author

AntonOresten commented Jan 24, 2026

I considered this — and I think the main reason I didn't was because of the ScalarFloat type union:

"""Scalar floating-point types supported by Tile IR (f16, tf32, f32, f64)."""
const ScalarFloat = Union{Float16, Float32, Float64, TFloat32}

which exists to distinguish between generic floats and ones that are supported in Tile IR. This type is extensively used for the method overlay definitions etc.

Furthermore this section with type unions mentions section 8.7 of the Tile IR spec which has many mentions of BFloat16.

In #36 I also discuss extending datatypes in an implementation-agnostic way. In the case of BFloat16, the type itself is defined in Core, so we could bind the name without the dependency, but I think it makes sense to be able to refer to it as ct.BFloat16 just like we can do ct.TFloat32, since they are likely to be used frequently.

@giordano
Copy link

Ah, fair enough, I missed the change to ScalarFloat in src/language/types.jl, all the other changes seemed doable in an extension.

@AntonOresten
Copy link
Contributor Author

Yeah, I agree. Thanks for bringing this up though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants