Saturday, 2022-05-07

octaviusHello, I was updating the repos, and noticed the wiki libreriscv repo gives me an automatic merge error:10:35
octaviusAutomatic merge failed; fix conflicts and then commit the result.10:35
octaviusopenpower/sv/cr_int_predication.mdwn10:35
octaviusIs this a known problem, have I not updated something? XD10:35
cesarHi octavius. I'm guessing you had a local commit that you forgot to push, which changed this file. Then, someone else modified that same file, and pushed. As you did a git pull, git was unable to reconcile the two modified versions of the same file.11:20
octaviusI did do a git reset --hard master, then a git pull origin master11:22
cesarLook for "<<<<<<<" and ">>>>>>>" on your copy of openpower/sv/cr_int_predication.mdwn, and try to see what the final version should look like.11:23
cesarTry using gitk --all, see if your "master" branch history diverged from "origin/master".11:26
cesarI think you can also use "git log origin/master..master" to see the commits you didn't push.11:29
cesarThe syntax a..b justly means: select commits of branch b that aren't in branch a.11:36
cesar(assuming you do have non-pushed commits)11:48
cesaroctavius: OK, it can also be the result of someone having done a forced push on the main repo.12:00
cesarUse "git log" or "git show" to see the hash, message and date of the last commit you have. Then, try to find the corresponding commit message (around the same date) on https://git.libre-soc.org/?p=libreriscv.git;a=shortlog12:08
cesarIf the hashes are different, then this confirms someone did a forced push, rewriting history.12:10
cesaroctavius: See: http://lists.libre-soc.org/pipermail/libre-soc-dev/2022-March/004624.html for information and instructions.12:53
cesar... so there was indeed a forced push after all. I've seem to remember the occasion.12:55
ghostmansd[m]lkcl: $(make check) for gas works if I change the operand index size from 8 bits to 1613:54
ghostmansd[m]However, note that we have 8 operand indices for each insn present in PPC13:55
ghostmansd[m]So, be sure, it does affect size of the binary13:56
ghostmansd[m]Any ideas on how to keep the same size are appreciated. I for sure don't want to re-invent the whole operand parsing as well as performing the binary output.13:57
ghostmansd[m]Also, something is broken in libbacktrace tests, $(make check) fails there upon linkage to some internal libbacktrace stuff, so I had to do some tricks (basically cutting the code which causes it). Waiting for the whole check to be completed.14:02
lkclghostmansd[m], nice. yyeah... one way to do it (sigh) would be to add a 2nd field, use a trick like ASN-1 or... wait, no, that wouldn't work either14:13
lkcli honestly wouldn't worry about increasing the size by 1 byte.14:14
ghostmansd[m]It's 1 byte for only one operand14:15
lkcli mean, it's what... 16,000 entries? so that's increasing something that's... what... 512kbytes already?14:15
ghostmansd[m]Yeah, kinda like this14:16
lkclwhat's the size of the opc-ppc struct (just one)14:16
lkclok so it goes up by 128k.14:16
lkcli mean, pffh14:16
ghostmansd[m]Ok then :-)14:16
lkcl32 bytes per struct?14:16
lkclmust be more than that14:16
lkclcall it 64 - that's 1mbyte.  12% increase is... pffh14:17
lkclif it was double or triple the overall size i'd say there's a chance the reviewers would be freaking out14:17
ghostmansdhttps://pastebin.com/ve9HtzHk14:17
lkclor if this was a gigabyte data struct, 12% is of concern14:17
ghostmansd(with unsigned short already)14:17
lkcl64+64+64+64+64+8x814:18
lkcl384 bytes14:18
lkclx16k14:18
lkclwait... sorry...14:18
lkcl8+8+8+8+8+8*814:19
lkcl104 bytes14:19
lkcl1.7 megabytes14:19
lkcl==> 2.7 megabytes by jumping to 16-bit14:19
lkclonly 1 mbyte increase... it's well outside of L1 cache sizes, but it was already well outside of L1 cache sizes14:20
lkclif efficiency was of serious concern they'd be using datadraw http://datadraw.sourceforge.net/14:20
lkclwhich is frickin awesome btw14:20
lkcland totally obscure14:21
ghostmansd[m]Wow14:21
ghostmansd[m]Thanks for the link14:21
lkcl7x faster than c, just by using macros14:21
lkclDataDraw14:22
lkcl14:22
lkcl3.8%14:22
lkcl14:22
lkcl1.3%14:22
lkcl14:22
lkcl7.83s14:22
lkcl14:22
lkcl432MB14:22
lkclC++/STL14:22
lkcl14:22
lkcl32.9%14:22
lkcl14:22
lkcl21.7%14:22
lkcl14:22
lkcl124.6s14:22
lkcl14:22
lkcl1.1GB14:22
lkclRaw C14:22
lkcl14:22
lkcl34.4%14:22
lkcl14:22
lkcl20.4%14:22
lkcl14:22
lkcl55.214:22
lkcl14:22
lkcl702MB14:22
lkcleek!14:22
lkcli will so end up getting rate-limited for that, sigh14:22
lkclDataDraw    3.8%    1.3%    7.83s   432MB14:23
lkclC++/STL 32.9%   21.7%   124.6s  1.1GB14:23
lkclRaw C   34.4%   20.4%   55.2    702MB14:23
lkclbetter14:23
ghostmansdlol14:24
lkclas i know you like the whole auto-generating-code thing, you'll love datadraw.  you write the data design in a Template Language14:25
lkcland the macros to access data in that format get auto-generated14:25
lkclcovering strings, hash-tables, graphs, enums, everything you'd normally need and assume that c structs would be "lightning quick" but aren't14:26
lkclall pointers are *relative* and are stored in something similar to ASN-1 (variable-length-encoded offsets)14:26
ghostmansdReally nice stuff, will check it more14:29
ghostmansdidk why, but it reminds me of http://www.catb.org/esr/structure-packing/14:30
lkclyes, except datadraw will do that job in an automated fashion16:02
lkclthe general idea is, the more you have to hit L1/L2 with misses, the more costly the access, even if a small amount of processing is required to "reconstruct" the data16:03
ghostmansd[m]lkcl, I finally got what the fuck happens in binutils macros and operands, and the thing is not that difficult, I already almost added setvl/setvl. support (only need to check whether it works)19:37
ghostmansd[m]It's nice that insn with that many operands is the first :-)19:37
lkclhooray!20:07
lkclwell, 3 of them could be merged into one 3-bit field20:07
lkclms/vs/vf20:07
lkclbut where's the fun in that?20:07
ghostmansd[m]Nope, these are logically separate operands, so not only no fun, but, rather, no point :-)21:06
ghostmansd[m]Ah, wait, I got it, you mean some 3-state... Well, yes then, no fun21:07
lkclthe hardware doesn't care about whether the assembler expresses 3 bits as QTY 3of 1-bit operands or as QTY 1of 3-bit operand, it's all the same21:36
ghostmansd[m]yeah that I got :-)22:51
ghostmansd[m]Ok I managed to produce "58 43 07 81" blob out of "setvl. 2, 3, 4, 0, 1, 1"22:52
ghostmansd[m]Took a while to debug and understand it, though, but still not that bad22:56
ghostmansd[m]I also refactored the magic insn (this time it's "sv.magic") so that it inserts/extracts RM field using the stuff we generate23:12
ghostmansd[m]It becomes easier and easier, just added svstep insns23:33
ghostmansd[m]BTW there's some code duplicated for sv.setvl and setvl (they're basically the same apart of prefix). I'm inclined to teach sv.setvl handling to fall into simple setvl after computing the prefix. Any objections?23:35
octaviuscesar, thank you very much! That was the issue :)23:36

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!