Tuesday, 2021-03-16

lkcllxo: i spoke to david, he suggested setting up a conf call with alain modra, bill schmidt12:53
lkcland the idea occurred to me that we could emit an SVP64 prefix as a 32-bit opcode12:54
lkclthen programmerjake mentioned that this could be done using gcc "predicate" condition matching similar how to thumb2 works in arm12:54
*** vup is now known as __vupbot13:43
*** __vupbot is now known as vup13:44
programmerjakemore specifically, it could probably be done like Thumb's IT instruction, rather than any specific gcc mechanism14:19
programmerjakelkcl lxo ^14:20
lxolkcl, I don't see what it is in thumb2 that you refer to by gcc "predicate" condition matching.  arm has predicated insns, and gcc uses predicates all over in insn definitions on all ports, so the term is a little ambiguous.  alas, nothing I could think of made sense16:57
lxoregardless, the compiler doesn't feel like the right place to compute and output svp64 prefixes, and depending on how separate you conceive of the prefix-outputter, it won't model the behavior of the subsequent insn, nor even state its operand requirements17:00
lxoprogrammerjake, please point me at the code fragment in gcc that you refer to as Thumb's IT instruction17:03
lxo(that is, assuming you've seen something in a gcc machine description file that seemed useful)17:06
programmerjakelxo: i didn't see anything in particular, I just know the IT instruction must be immediately followed by the instruction that is conditionally executed -- kinda like the svp64 prefix must immediately be followed by the prefixed base instruction17:14
programmerjakesorry if that's not useful17:14
lxoprogrammerjake, I see.  yeah, I'm afraid there's no such thing as modeling of the IT instruction in gcc.  that's not how things work.  insns mode behaviors (copying, computing, etc), not specific opcodes.  there are multiple patterns that output an it opcode followed immediately by another opcode, but nothing that models "it" per se17:19
lxo(I'd have been very very surprised if there was, FWIW :-)17:19
lxoinsns mode{+l+} behaviors, in case my typo made it horribly confusing ;-)17:21
programmerjakeso, the patterns your adding to gcc to generate svp64 instructions from IR vectors can use the same approach...each pattern generates the svp64 prefix and the base instruction together all in the same assembly string17:22
programmerjakeyeah, I'd figured out you meant model17:23
programmerjakethough I guess my idea's obvious in retrospect17:24
lkcllxo: if the prefix is not computed (as a .long or as any other magic constant) but instead is expressed as what we originally intended the "sv.op/yyy/zzz/aa/bb" syntax to be17:29
lxolkcl, even as a string, it still has to be computed, as it holds part of the operands for the prefixed opcode17:54
lxoprogrammerjake, yeah, that's what I'm already doing17:55
lkcllxo: yes.  that would still have to be done even with the sv.xxx/yy=N/zz=M syntax17:59
lkclchanges the behaviour, sets modes (saturation), sets the element width to 8-bit, augments registers.18:00
lkclthat all has to happen - it's just that the thought of that being intrusively embedded into every single scalar macro is freaking out the gcc ppc devs18:01
lkclconsequently if it can be done *literally* as a prefix opcode that doesn't require the scalar operations and associate macros to be intrusively modified (if at all) that's a huge benefit18:02
lkclwe could probably get away with a big uniform patch "set attr 'svp64_prefixable "yes""18:02
lxoI can't imagine how prefixing could be implemented without actually changing the code that parses macros.  it wouldn't even be able to parse our extended registers19:53
lxoit looks I'm going to be late for the VC meeting; I'm in another meeting ATM, and it doesn't look like it's wrapping up22:01
lkclsck no problem22:01
programmerjakecole & others: meeting now...22:05

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