This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly][NFC] Refactor SIMD load/store tablegen defs
ClosedPublic

Authored by tlively on Dec 21 2020, 12:47 PM.

Details

Summary

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.

Diff Detail

Event Timeline

tlively created this revision.Dec 21 2020, 12:47 PM
tlively requested review of this revision.Dec 21 2020, 12:47 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 21 2020, 12:47 PM

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:
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?

Wow, I didn't know we can do OOP in TableGen! (Are these new functionalities?)

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:

  • The record name (I8x16) needs to be distinct from the name of anything else we might need to reference.
  • We need the vt; it is probably the most commonly used member.
  • prefix and vprefix appear in instruction names, so we need them, too.

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??

tlively added inline comments.Dec 22 2020, 10:42 AM
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.

tlively updated this revision to Diff 313415.Dec 22 2020, 12:42 PM
aheejin accepted this revision.Dec 22 2020, 3:36 PM

Nice!

This revision is now accepted and ready to land.Dec 22 2020, 3:36 PM
This revision was landed with ongoing or failed builds.Dec 22 2020, 8:06 PM
This revision was automatically updated to reflect the committed changes.