Introduce Vec records, each bundling all information related to a single SIMD
lane interpretation. This lets TableGen definitions take a single Vec parameter
from which they can extract information rather than taking multiple redundant
parameters. This commit refactors all of the SIMD load and store instruction
definitions to use the new Vecs. Subsequent commits will similarly refactor
additional instruction definitions.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
70 ms | x64 windows > LLVM.CodeGen/XCore::threads.ll |
Event Timeline
Wow, I didn't know we can do OOP in TableGen! (Are these new functionalities?)
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td | ||
---|---|---|
57–58 | Do we need to separately maintain 4 different fields with the same info: |
Looking at the git logs, it looks like defvar was introduced in January in https://reviews.llvm.org/D71407. I think defining records to collect data and passing them as parameters to other records has been possible for a long time, but I certainly didn't realize that when I was first learning tablegen 2+ years ago.
In case you're interested, here's a lightning talk from the 2019 LLVM developers meeting about functional programming in tablegen: https://www.youtube.com/watch?v=dIEVUlsiktQ. IIRC, catching the last few minutes of that talk in person is what made me start thinking that maybe there was some way to make our SIMD tablegen nicer.
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td | ||
---|---|---|
57–58 | Unfortunately we need all of these as far as I can see:
In principle we could possibly construct some of these members from other members using string manipulations and !cast. But unless we want to write the code for that at every use site, we would need to store the results somewhere so they can be reused. It's simplest to just store them as fields on the Vec in the first place. |
Thanks for the info!
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td | ||
---|---|---|
57–58 | Yeah I think using things like !casts are cumbersome and not really worth it. But I couldn't find any uses of strings in the form of v8x16 (vprefix here) in either of these:
All of them seem to use i8x16 form. But looking at our LLVM tests we seem to be using both. For example, our tests contain v8x16.shuffle, but the SIMD docs have i8x16.shuffle. I'm not sure why we use different forms, but maybe we can merge prefix and vprefix?? |
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td | ||
---|---|---|
57–58 | Ah right, I forgot that we renamed all the instructions that used the v names back in August: https://github.com/WebAssembly/simd/issues/316. I'll open a different patch to do that renaming first so we can simplify this one and still keep it as NFC. |
Do we need to separately maintain 4 different fields with the same info:
I8x16 (in def), vt (v16i8), prefix (i8x16), and vprefix (v8x16)
Maybe it can be hard to unify all of these, but can we merge some?