When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review,
but these are all the type conflicts found (all legitimate) by my
locally-patched TableGen.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Unit Tests
Time | Test | |
---|---|---|
6,200 ms | x64 debian > libarcher.races::task-dependency.c |
Event Timeline
Comment Actions
Funnily enough I was just revisiting this last night. The AMDGPU review stalled for ages by which point AArch64 had moved on and the patches no longer worked as-is. I have something that compiles and passes all tests again but need to compare TableGen .inc files before and after again to make sure no subtle changes have crept in. So I hope to have an updated version of this review later today.
Comment Actions
Rebased after patch series held up on another review for several months
Changes:
- Trivial merge conflict resolution due to sve_ext_imm_0_* being renamed
- Split sve_cnt_mul_imm into i32 and i64 versions due to being used as both
- NB: The i32-using isel pattern (which is the one that gave type conflicts after rebasing, since previously the complex pattern was only ever used as an i64 so I just changed it to that, like sve_cnt_shl_imm still is) doesn't appear to have test coverage, as commenting out the new isel pattern entirely passed all llvm/lib/CodeGen/AArch64 tests
Comment Actions
Thanks @jrtc27. Once the patch lands I'll see about fixing the missing test coverage.