Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
After playing with it a bit, it feels like cloning whole test files is too much clutter and adding RUN lines along with functional changes without pre-committed tests is uncomfortably unsafe, so maybe doing it the usual way is still the best option.
After playing with it a bit, it feels like cloning whole test files is too much clutter and adding RUN lines along with functional changes without pre-committed tests is uncomfortably unsafe, so maybe doing it the usual way is still the best option.
Good, I agree.
Could we have a minimal 16-bit test for the bringup? One that tests all the basic 16-bit ops work on both paths, but maybe doesn't bother trying to handle all the vector types and other complexities
Can you describe that a bit more? I would say the existing tests in tree have coverage of MC and Codegen for the fake16 and previous asic paths. And then it seems adding tests for the true16 path would mean a lot of them are xfail right now. But I do think more VOP2 true16 instructions than just add_f16 are functioning after the current patch stack. Perhaps we could add tests for those, such as mul_f16, sub_f16 etc.
I mean like for wave32, we have test/CodeGen/AMDGPU/wave32.ll. It's not completely comprehensive, but it kept testing isolated when wave32 support was first added. At this point a lot of what's in it is probably redundant and duplicated in other tests
I mean like for wave32, we have test/CodeGen/AMDGPU/wave32.ll. It's not completely comprehensive, but it kept testing isolated when wave32 support was first added. At this point a lot of what's in it is probably redundant and duplicated in other tests
As Joe mentioned, we already have lots of t16 tests here, currently covering the support for fake instructions, but identical to what we would want for real ones, so feels like no need for special bring-up tests.