| octavius | Hello, I was updating the repos, and noticed the wiki libreriscv repo gives me an automatic merge error: | 10:35 |
|---|---|---|
| octavius | Automatic merge failed; fix conflicts and then commit the result. | 10:35 |
| octavius | openpower/sv/cr_int_predication.mdwn | 10:35 |
| octavius | Is this a known problem, have I not updated something? XD | 10:35 |
| cesar | Hi 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 |
| octavius | I did do a git reset --hard master, then a git pull origin master | 11:22 |
| cesar | Look 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 |
| cesar | Try using gitk --all, see if your "master" branch history diverged from "origin/master". | 11:26 |
| cesar | I think you can also use "git log origin/master..master" to see the commits you didn't push. | 11:29 |
| cesar | The 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 |
| cesar | octavius: OK, it can also be the result of someone having done a forced push on the main repo. | 12:00 |
| cesar | Use "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=shortlog | 12:08 |
| cesar | If the hashes are different, then this confirms someone did a forced push, rewriting history. | 12:10 |
| cesar | octavius: 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 16 | 13:54 |
| ghostmansd[m] | However, note that we have 8 operand indices for each insn present in PPC | 13:55 |
| ghostmansd[m] | So, be sure, it does affect size of the binary | 13: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 |
| lkcl | ghostmansd[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 either | 14:13 |
| lkcl | i honestly wouldn't worry about increasing the size by 1 byte. | 14:14 |
| ghostmansd[m] | It's 1 byte for only one operand | 14:15 |
| lkcl | i mean, it's what... 16,000 entries? so that's increasing something that's... what... 512kbytes already? | 14:15 |
| ghostmansd[m] | Yeah, kinda like this | 14:16 |
| lkcl | what's the size of the opc-ppc struct (just one) | 14:16 |
| lkcl | ok so it goes up by 128k. | 14:16 |
| lkcl | i mean, pffh | 14:16 |
| ghostmansd[m] | Ok then :-) | 14:16 |
| lkcl | 32 bytes per struct? | 14:16 |
| lkcl | must be more than that | 14:16 |
| lkcl | call it 64 - that's 1mbyte. 12% increase is... pffh | 14:17 |
| lkcl | if it was double or triple the overall size i'd say there's a chance the reviewers would be freaking out | 14:17 |
| ghostmansd | https://pastebin.com/ve9HtzHk | 14:17 |
| lkcl | or if this was a gigabyte data struct, 12% is of concern | 14:17 |
| ghostmansd | (with unsigned short already) | 14:17 |
| lkcl | 64+64+64+64+64+8x8 | 14:18 |
| lkcl | 384 bytes | 14:18 |
| lkcl | x16k | 14:18 |
| lkcl | wait... sorry... | 14:18 |
| lkcl | 8+8+8+8+8+8*8 | 14:19 |
| lkcl | 104 bytes | 14:19 |
| lkcl | 1.7 megabytes | 14:19 |
| lkcl | ==> 2.7 megabytes by jumping to 16-bit | 14:19 |
| lkcl | only 1 mbyte increase... it's well outside of L1 cache sizes, but it was already well outside of L1 cache sizes | 14:20 |
| lkcl | if efficiency was of serious concern they'd be using datadraw http://datadraw.sourceforge.net/ | 14:20 |
| lkcl | which is frickin awesome btw | 14:20 |
| lkcl | and totally obscure | 14:21 |
| ghostmansd[m] | Wow | 14:21 |
| ghostmansd[m] | Thanks for the link | 14:21 |
| lkcl | 7x faster than c, just by using macros | 14:21 |
| lkcl | DataDraw | 14:22 |
| lkcl | 14:22 | |
| lkcl | 3.8% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 1.3% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 7.83s | 14:22 |
| lkcl | 14:22 | |
| lkcl | 432MB | 14:22 |
| lkcl | C++/STL | 14:22 |
| lkcl | 14:22 | |
| lkcl | 32.9% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 21.7% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 124.6s | 14:22 |
| lkcl | 14:22 | |
| lkcl | 1.1GB | 14:22 |
| lkcl | Raw C | 14:22 |
| lkcl | 14:22 | |
| lkcl | 34.4% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 20.4% | 14:22 |
| lkcl | 14:22 | |
| lkcl | 55.2 | 14:22 |
| lkcl | 14:22 | |
| lkcl | 702MB | 14:22 |
| lkcl | eek! | 14:22 |
| lkcl | i will so end up getting rate-limited for that, sigh | 14:22 |
| lkcl | DataDraw 3.8% 1.3% 7.83s 432MB | 14:23 |
| lkcl | C++/STL 32.9% 21.7% 124.6s 1.1GB | 14:23 |
| lkcl | Raw C 34.4% 20.4% 55.2 702MB | 14:23 |
| lkcl | better | 14:23 |
| ghostmansd | lol | 14:24 |
| lkcl | as i know you like the whole auto-generating-code thing, you'll love datadraw. you write the data design in a Template Language | 14:25 |
| lkcl | and the macros to access data in that format get auto-generated | 14:25 |
| lkcl | covering strings, hash-tables, graphs, enums, everything you'd normally need and assume that c structs would be "lightning quick" but aren't | 14:26 |
| lkcl | all pointers are *relative* and are stored in something similar to ASN-1 (variable-length-encoded offsets) | 14:26 |
| ghostmansd | Really nice stuff, will check it more | 14:29 |
| ghostmansd | idk why, but it reminds me of http://www.catb.org/esr/structure-packing/ | 14:30 |
| lkcl | yes, except datadraw will do that job in an automated fashion | 16:02 |
| lkcl | the 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 data | 16: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 |
| lkcl | hooray! | 20:07 |
| lkcl | well, 3 of them could be merged into one 3-bit field | 20:07 |
| lkcl | ms/vs/vf | 20:07 |
| lkcl | but 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 fun | 21:07 |
| lkcl | the 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 same | 21: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 bad | 22: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 generate | 23:12 |
| ghostmansd[m] | It becomes easier and easier, just added svstep insns | 23: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 |
| octavius | cesar, 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/!