00:05 karolherbst: mhh, applied the old commit and now magically I get better results again... let me see what's going on here
00:16 karolherbst: HdkR: ohh, local CSE :/
00:16 karolherbst: in my first try I used the same address for every propagated immediate
00:17 karolherbst: mhhhhhhhh
00:17 karolherbst: I should look into deduplicating indeed
00:18 HdkR: :D
00:18 HdkR: Shouldn't be too terrible
00:25 karolherbst: yeah... I just need to use an unordered_map
00:59 karolherbst: HdkR: uff, figured out some of the hurts
00:59 karolherbst: sat mad ftz f32 $r2 $r2 $r3 neg c0[0x0] vs sat mad ftz f32 $r3 $r2 c15[0x86a0] neg $r3 (8)
01:00 karolherbst: one immediate shared by three mad got moved into c0[], but they each used a difference value form c0[]
01:00 karolherbst: so now I've got +2 mov
01:00 HdkR: ah
01:00 karolherbst: *different
01:01 karolherbst: mhhh, that is annoying
01:01 karolherbst: instructions can
01:01 karolherbst: 't have both anyway
01:01 karolherbst: (except stupid exceptions we don't have to care about)
02:31 karolherbst: HdkR: *sigh*... the other hurts I've got are due to the c = fma(a, b, c) form :/
02:31 karolherbst: uhm
02:31 karolherbst: c = fma(a, limm, c)
02:36 HdkR: karolherbst: How are those hurt?
02:36 karolherbst: HdkR: fma(a, c0, c1)
02:37 HdkR: ah, so you get a mov in that case
02:37 karolherbst: yeah
02:37 karolherbst: it's a bit more complicated though
02:37 karolherbst: think about same constant used multiple times
02:39 karolherbst: mhh, actually, it's RA messing up
02:39 karolherbst: mov u32 $r6 0x3f94fdf4 (8)
02:39 karolherbst: mad ftz f32 $r6 $r6 $r0 $r1 (8)
02:40 karolherbst: but anyway, for fmas/mads we don't really have to do that opt, if it can take a limm post RA :/
02:40 karolherbst: messy
02:40 HdkR: Yea, you just have to make sure than any instructions that can fit the immediate use the immediate form
02:41 HdkR: It's a fitting problem :P
02:45 karolherbst: but currently I am at gpr: 5114/71 inst: 21817/29 helped/hurt
02:45 karolherbst: so maybe it doesn't matter all that much
03:10 HdkR: I think that is up to you, if you want to forgo the additional work required to remove some of those movs :P
12:47 karolherbst: mhhh
12:47 karolherbst: the second run of a unigine benchmark gives me 10% lower scores... weird
13:11 karolherbst: mupuf: btw, is there a way in ezbench to just do a "quick" benchmark of a git commit locally? I really dont want to bother with setting up the daemon and everything and just perf check a mesa commit
14:55 mupuf: karolherbst: sure, just say start instead of run