In the same manner as struct.buffer.load / struct.buffer.store,
allow struct.buffer.load.format / struct.buffer.store.format to
return / accept any type. This simplifies front-end code gen.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Needs d16 tests, and needs GlobalISel tests. I believe there was a reason format buffer intrinsics needed to be assumed to be FP, but maybe it doesn't matter
Comment Actions
I have added d16 tests. This already includes GlobalISel tests, unless I missed something?
I am hoping Tim Renouf (@tpr) can comment why the original intrinsics assumed FP.
Comment Actions
I don't know of any reason why it has to be fp. Maybe related to the prehistoric thing where isel used to need something to be fp to put it in a vgpr?
Comment Actions
I think the important part was not changing the register layout vs. integer and FP. If these are assumed to always use the expected FP register layout in the d16 case, this is fine