Saturday, 2021-07-03

openpowerbot[irc] <vpandya> IIUC svp64 instructions are of following format10:47
openpowerbot[irc] <vpandya> `sv.asmcode/mode.vec{N}.ew=8,sw=16,m={pred},sm={pred} reg.v, src.s`10:47
openpowerbot[irc] <vpandya> I am not able to find 64 bit instructions on OpenPower ISA v3.1 page11:06
openpowerbot[irc] <vpandya> is it something libre-soc proposing?11:06
openpowerbot[irc] <lkcl> vpandya: yes.11:25
openpowerbot[irc] <lkcl> more like: sv.asmcode/vec{N}/ew=N/sw=N reg.{vs}, src1.{vs}, src2.{vs}11:26
openpowerbot[irc] <lkcl> we _may_ have to change the "=" to something else because it conflicts with the gnu-as macro use of "="11:27
openpowerbot[irc] <lkcl> you may have missed this, yesterday:
openpowerbot[irc] <lkcl> or it looks like i forgot to mention: see in the Makefile, we have to run a "pre-processing" phase11:29
openpowerbot[irc] <lkcl> which turns "sv.asmcode/...." into ".long 0xNNNNNNN asmcode ...."11:29
lkcllxo: we're starting to need that binutils support11:30
openpowerbot[irc] <lkcl> vpandya, btw one thing we do not want to be doing is to *hand-write* the SVP64 encoder/detecters.11:36
openpowerbot[irc] <lkcl> that's a resounding No.11:37
openpowerbot[irc] <lkcl> there's a program,, which can be used to auto-generate header files, data structures, etc. etc. which allow detection / parsing / support of SVP6411:38
lkclvpandya: this is a great document, very clear
lxolkcl, thanks for letting me know.  I've been having trouble getting myself to work on it.  hopefully this knowledge will make it easier rather than harder.  I still don't fully understand what's going on with me11:52
lxoI recall we'd run into an issue WRT generated files and corresponding sources at some point, has that been sorted out yet?11:53
openpowerbot[irc] <vpandya> In llvm world , back end can be written with domain specific language called tablegen. Information from .Td files are used in all places in llvm back end12:02
lkcllxo: i've been there. it feels like you've an engine revving at 5,000 RPM but "nothing moves forward"12:12
lkclit was more, "if the SVP64-parser-table sources are written by hand this is not only a waste of time it's also very risky"12:13
lkclso i would greatly - strongly - prefer that any tables used in gas / gcc are auto-generated12:14
lkclvpandya: great.  ok so once we know what the format is (by making one or two by hand, first - same for you, lxo) then we will need an auto-generator in to create a table which can be included in the .Td file12:18
lkclwe absolutely do not need the hassle of 200+ hand-edited SVP64 parsing files in *two* compilers getting wildly out of sync.12:18
lkclplus the format may need to change, and now the corresponding tables are out-of-date12:19
openpowerbot[irc] <vpandya> Auto generation of td file feels like research project of itsself , I know even in big orgs people are trying that12:19
lkclvpandya: at least some tables which are #included12:25
lkcl1 sec i will find something12:25
lkcllike this.12:27
lkclthat's entirely *auto-generated*12:27
lkclso that whomever adds SVP64 to microwatt does *not* have to type out those lines by hand12:27
lkcldoesn't end up making transliteration mistakes12:27
lkcland doesn't have the hassle of being told, "sorry, we changed the format, you have to update line 132 column 5 with some arbitrary 1-bit change"12:28
lkcllikewise, this is auto-generated as well:12:29
lkclvpandya: SVP64 is incredibly regular and strongly well-defined12:32
lkclthis is very, very deliberate.12:32
lkclwe have had recommendations to have rules such as "if XYZ then the format changes" and i have, every single time, said NO.12:33
lkcljust recently (last week) to support LD/ST bit-reversing, i experimented for the very first time to allow an "override" (a new LD format), and it was absolute hell12:34
lkclit was so bad that ordinarily i would have said "no damn way in hell this is going into SVP64"12:35
lkclbut it's for FFT and DCT which has so many applications and such high importance i very reluctantly let it in12:35
*** jn <jn!~quassel@user/jn/x-3390946> has left #libre-soc12:37
lkclbottom line, unlike other ISAs where i would expect them to struggle to auto-generate anything useful, SVP64 is sufficiently abstracted and regular that it can be.12:40
lkclby the time you've done even two examples by hand, the patterns should be blindingly obvious.12:40
lkclwait... hang on...13:19
lkclvpandya: does the LLVM-IR phase emit *binaries* or does it emit *assembler*?13:20
lkclif it's assembler, please ignore everything i said above :)13:20
lkclbecause it's the process of turning SVP64 *assembler* into *binary* that is regular.13:20
openpowerbot[irc] <vpandya> It can emit assembly or ELF both ,13:35
lkclvpandya: okaaay. i see.  ok, then the binary generation should be using auto-generated tables which match the regular patterning of SVP64, exactly as is done here;a=blob;f=src/openpower/sv/trans/;hb=HEAD14:15
lkclor, similar, you know what i mean14:15
lkclbut if emitting assembler, that will need to be done by hand, non-automated.14:15
lkclgiven that that tool,, can perform the translation from "sv.{asm}" into ".long {asm}" right now, the most productive use of time is to use it, as a post-processing tool, just like is done in the MP3 examples.14:18 understands ".set {regnum} tosomething" syntax so you can emit simple macros14:18
lkclif you need anything more than simple macros, we'll need the full binutils gas program to understand svp6414:19
openpowerbot[irc] <vpandya> for `sv.asmcode/mode.vec{N}.ew=8,sw=16,m={pred},sm={pred} reg.v, src.s`15:25
openpowerbot[irc] <vpandya> I think every thing related to mode, vec, ew, ... should be common15:25
openpowerbot[irc] <vpandya> in llvm's .TD15:25
openpowerbot[irc] <vpandya> only thing changes is asmcode15:25
openpowerbot[irc] <vpandya> unless if I misunderstood and there can be some condition on other fields based on asmcode15:26
openpowerbot[irc] <vpandya> for tablegen pattern matching it will be large based on number of combinations of all fields15:27
openpowerbot[irc] <vpandya> that can be improved later with automatically generating patterns15:28
lkclbasically that's it, yes. there should be absolutely no relation whatsoever between the prefix and the suffix (no limitation that is)15:36
lkclexcept, duh, of course, that, y'know, some v3.0B asm opcodes have 3 regs, some have 2, some even have 415:36
openpowerbot[irc] <vpandya> I am checking if llvm already has ppc backend that supports OpenPower ISA v3.115:37
lkclv3.1? that's quite unlikely.15:37
openpowerbot[irc] <vpandya> yes :(15:37
lkcland it's a dead-end for us anyway15:37
openpowerbot[irc] <vpandya> that may increase work15:37
lkclas in: there's nothing useful that it would add for us15:37
openpowerbot[irc] <vpandya> but I would like to explore what can be done15:38
lkclas in: we don't do SVP64-of-v3.115:38
lkclit would need 3x32 = 96-bit opcodes15:39
lkcland that's too much15:39
lkclit's far too complicated at this early stage15:40
lkclbtw one thing: there are concepts in SVP64 that simply don't exist in any other ISA.15:40
lkcltwin-predication is a good example.15:40
lkclone predicate mask for the source, one predicate mask for the destination15:41
openpowerbot[irc] <vpandya> SVP64 backend in LLVM is very instersting project15:41
lkclyes. it's quite challenging to do elegantly.15:42
openpowerbot[irc] <vpandya> yes15:42
lkclkeep in mind, always, that it's basically a hardware for-loop15:42
lkcla generic hardware-level for-loop (like x86 "REP" instruction)15:43
lkclVideoCore IV GPU also has the same concept15:43
lkcland the recent introduction of ARM SVE/SVE2 will make life a little easier15:43
openpowerbot[irc] <vpandya> for MESA based flow, we need LLVM15:57
openpowerbot[irc] <vpandya> otherwise develop complete flow with something like ACO15:57

Generated by 2.17.1 by Marius Gedminas - find it at!