| lkcl | lxo: i spoke to david, he suggested setting up a conf call with alain modra, bill schmidt | 12:53 |
|---|---|---|
| lkcl | and the idea occurred to me that we could emit an SVP64 prefix as a 32-bit opcode | 12:54 |
| lkcl | then programmerjake mentioned that this could be done using gcc "predicate" condition matching similar how to thumb2 works in arm | 12:54 |
| *** vup is now known as __vupbot | 13:43 | |
| *** __vupbot is now known as vup | 13:44 | |
| programmerjake | more specifically, it could probably be done like Thumb's IT instruction, rather than any specific gcc mechanism | 14:19 |
| programmerjake | lkcl lxo ^ | 14:20 |
| lkcl | okaay | 15:19 |
| lxo | lkcl, 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 sense | 16:57 |
| lxo | regardless, 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 requirements | 17:00 |
| lxo | programmerjake, please point me at the code fragment in gcc that you refer to as Thumb's IT instruction | 17:03 |
| lxo | (that is, assuming you've seen something in a gcc machine description file that seemed useful) | 17:06 |
| programmerjake | lxo: 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 instruction | 17:14 |
| programmerjake | sorry if that's not useful | 17:14 |
| lxo | programmerjake, 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 se | 17:19 |
| lxo | (I'd have been very very surprised if there was, FWIW :-) | 17:19 |
| programmerjake | k | 17:19 |
| lxo | insns mode{+l+} behaviors, in case my typo made it horribly confusing ;-) | 17:21 |
| programmerjake | so, 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 string | 17:22 |
| programmerjake | yeah, I'd figured out you meant model | 17:23 |
| programmerjake | though I guess my idea's obvious in retrospect | 17:24 |
| lkcl | lxo: 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 be | 17:29 |
| lxo | lkcl, even as a string, it still has to be computed, as it holds part of the operands for the prefixed opcode | 17:54 |
| lxo | programmerjake, yeah, that's what I'm already doing | 17:55 |
| lkcl | lxo: yes. that would still have to be done even with the sv.xxx/yy=N/zz=M syntax | 17:59 |
| lkcl | changes the behaviour, sets modes (saturation), sets the element width to 8-bit, augments registers. | 18:00 |
| lkcl | that 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 devs | 18:01 |
| lkcl | consequently 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 benefit | 18:02 |
| lkcl | we could probably get away with a big uniform patch "set attr 'svp64_prefixable "yes"" | 18:02 |
| lxo | I 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 registers | 19:53 |
| lxo | it 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 up | 22:01 |
| lkcl | sck no problem | 22:01 |
| lkcl | s/sck/ack | 22:01 |
| programmerjake | cole & others: meeting now... | 22:05 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!