| *** vup2 is now known as vup | 13:06 | |
| lkcl_ | lxo: what's this? https://github.com/gcc-mirror/gcc/blob/a1e4fc19d99af3964588d3770cbf52e160d5b24b/gcc/config/rs6000/rs6000.md#L2538 | 17:38 |
|---|---|---|
| lkcl_ | mode in the define_insn matching up with <wd> later down | 17:39 |
| lkcl_ | likewise here https://github.com/gcc-mirror/gcc/blob/a1e4fc19d99af3964588d3770cbf52e160d5b24b/gcc/config/rs6000/rs6000.md#L3124 | 17:42 |
| lkcl_ | and this one define_expand "<u>mul<mode><dmode>3" | 17:43 |
| lkcl_ | tells me that something involving a further macro-substitution "<sv>insn<svqual>" may be possible to create "sv.insn/stuff" | 17:47 |
| lxo | lkcl_, mode iterators | 18:53 |
| lxo | it is macro substitution indeed, but only over a predefined set of modes | 18:57 |
| lxo | look for define_mode_iterator to see the definitions of the sets, and define_mode_attr for other substitutions associated with it | 18:58 |
| lxo | theré s also define_code_iterator, that performs macro substitution of rtl codes (operations like plus, extend, truncate) to a set of rtl codes | 18:59 |
| lxo | again, there may be attributes for substitutions associated with them. that's where the <u> comes from in the mul case you pointed out | 19:00 |
| lxo | there are code iterators over {sign,zero}_extend, and over {unsigned_,}fix, and <u> is defined as "u" for the unsigned variants, and nothing for the signed ones | 19:02 |
| lxo | so that the substituted pattern names take the form expected by gcc generic code generator, such as umulsidi3, that it looks for to expand an unsigned widening multiply of a single integer, yielding a double integer | 19:03 |
| lkcl_ | lxo, got it | 19:04 |
| lxo | we are using mode iterators, and will likely use code iterators too, to introduce svp64 prefixed opcodes in gcc | 19:05 |
| lxo | altivec and vsx compatibility made it pretty much impossible to just tack on a prefix and be done with it, because they'd grown multiple interrelated patterns | 19:07 |
| lxo | if we're to fork, we might be able to clean things up, but it's not obvious that it will make for any less, or even any easier work | 19:07 |
| lxo | one more thing to keep in mind: some patterns in machine descriptions are expected to be there, and to take certain predefined names, because they're looked for by the rtl expander | 19:09 |
| lxo | others may take up nonstandard names, or even no names, and be variants or auxiliary for other patterns, or just name other patterns that the expander won't select or look for, but that the insn combiner may generate by means of arithmetic substitution | 19:10 |
| lkcl_ | wha-howww | 21:24 |
| lkcl_ | and a fork will just have exactly the same code anyway, more or less, and require the exact same patches/fixes/additions from v3.0 and v3.1 | 21:25 |
| lkcl_ | and probably require large amounts of platform code duplication | 21:26 |
| lkcl_ | meeting 35 mins | 21:26 |
| lkcl_ | cesar[m]1, ^ | 21:26 |
| lkcl_ | lxo, ^ | 21:26 |
| lkcl_ | programmerjake[m, ^ | 21:26 |
| lxo | the further it diverges, the harder it will be to merge it back together, so even if we go through with a separate machine name, forced to go our separate way, we're probably better off proceeding as if we knew we'd merge back together eventually | 21:28 |
| cesar[m]1 | lkcl_: If an instruction has a SVP64 prefix, and VL==0, but no register is a vector, then we should really execute that instruction, right? For instance: sv.add 1, 5, 9 | 21:46 |
| lkcl_ | no. if VL==0 it's a for-loop "for i = 0 to 0" | 21:47 |
| lkcl_ | lxo: yehyeh. | 21:48 |
| lxo | cesar[m]1, lkcl_, if none of the operands is a vector, why would we even look at VL? | 21:49 |
| cesar[m]1 | What about "scalar identity"? Is not sv.add 1, 5, 9 identical to add 1, 5, 9, no matter what VL is? | 21:49 |
| lxo | I'd have thought so | 21:55 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!