IRC logs for #openrisc Monday, 2012-05-21

stekernI just added support for l.cmov in llvm, now I just need some hardware that supports it...06:51
juliusbhi jose16:01
jeremybennettHi all16:02
juliusbstekern: l.cmov huh? in which situations does LLVM use that?16:02
stekernjuliusb: in rather many16:04
stekernsomevar = somecond ? opt1 : opt2;16:05
stekernfor example ;)16:05
juliusbyeah that's great16:07
stekernselect_cc gets lowered into it, instead of l.sfxx; skip;16:07
juliusbthat seems like a much better way to do things than branching over an assign16:07
juliusbbranching is expensive :(16:07
stekernI'm rather certain our gcc port could use it to, if someone put in support for it16:08
juliusbhave you got any benchmark software running on LLVM yet?16:15
juliusbor rather, compiling on LLVM yet which you can then run and evaluate?16:15
juliusbI guess you need the HW support for l.cmov as you mentioned16:15
stekernor1ksim does support it, but that one isn't really reliable for benchmarking, so I'm planning on implementing it in your mor1kx baby ;;)16:18
stekernas far as benchmarks goes, I've ran dhrystone and coremark on or1200 and mor1kx comparing gcc4.5.1, gcc4.8.0 and llvm16:22
stekernresult is: mor1kx is about 33% faster in coremark than or1200, in the order of speed: gcc4.8, gcc4.5.1 llvm16:24
stekerngcc4.8 produces better results than gcc4.5.1 on mor1kx, while gcc4.5.1 produces better results than gcc4.8.0 on or120016:26
stekernmor1kx is faster in dhrystone than or120016:28
juliusbwow one third faster, i'm a little bit surprised16:28
juliusbthat branching thing must be cheaper in mor1kx ;)16:29
stekernguess so :)16:29
stekerngrepping for l.cmov in coremark shows 14 instances when compiled with cmov support, will be interesting to see the results when compared to it compiled without it16:42
stekernand how much area it will steal to implement it16:43
stekernshouldn't be that much, a mux and a bit of control logic16:44
juliusbyeah, I'd expect marginal increase in area16:48
juliusbif you put it through the ALU, and just mux out the result based on the flag16:48
stekernyup, that's the plan ;)16:48
juliusbcmov_result = flag ? a : b;16:48
stekernexactly, my guess is that it's more work feeding back the flag into the alu (i.e. wiring in the top module) than to implement it =p17:34
juliusbyou could be lazy and just register it thre in the ALU too, to save doing the wiring ;)17:42
juliusbwe calculate it in the ALU and when to write it, so you have the info in that module17:42
juliusbmaybe the synthesis tool be smart enough to optimise it away, but i doubt it17:43
stekernyeah, I saw that, but there's some glue logic to sr[f] and the clear/set so I think it still might be clearer to feed back the "ready-made" flag17:45
* juliusb agrees18:45

Generated by 2.15.2 by Marius Gedminas - find it at!