Tuesday, 2021-03-09

*** vup2 is now known as vup13:06
lkcl_lxo: what's this? https://github.com/gcc-mirror/gcc/blob/a1e4fc19d99af3964588d3770cbf52e160d5b24b/gcc/config/rs6000/rs6000.md#L253817:38
lkcl_mode in the define_insn matching up with <wd> later down17:39
lkcl_likewise here https://github.com/gcc-mirror/gcc/blob/a1e4fc19d99af3964588d3770cbf52e160d5b24b/gcc/config/rs6000/rs6000.md#L312417: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
lxolkcl_, mode iterators18:53
lxoit is macro substitution indeed, but only over a predefined set of modes18:57
lxolook for define_mode_iterator to see the definitions of the sets, and define_mode_attr for other substitutions associated with it18:58
lxotheré s also define_code_iterator, that performs macro substitution of rtl codes (operations like plus, extend, truncate) to a set of rtl codes18:59
lxoagain, there may be attributes for substitutions associated with them.  that's where the <u> comes from in the mul case you pointed out19:00
lxothere 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 ones19:02
lxoso 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 integer19:03
lkcl_lxo, got it19:04
lxowe are using mode iterators, and will likely use code iterators too, to introduce svp64 prefixed opcodes in gcc19:05
lxoaltivec 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 patterns19:07
lxoif 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 work19:07
lxoone 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 expander19:09
lxoothers 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 substitution19:10
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.121:25
lkcl_and probably require large amounts of platform code duplication21:26
lkcl_meeting 35 mins21:26
lkcl_cesar[m]1, ^21:26
lkcl_lxo, ^21:26
lkcl_programmerjake[m, ^21:26
lxothe 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 eventually21:28
cesar[m]1lkcl_: 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, 921:46
lkcl_no.  if VL==0 it's a for-loop "for i = 0 to 0"21:47
lkcl_lxo: yehyeh.21:48
lxocesar[m]1, lkcl_, if none of the operands is a vector, why would we even look at VL?21:49
cesar[m]1What about "scalar identity"? Is not sv.add 1, 5, 9 identical to add 1, 5, 9, no matter what VL is?21:49
lxoI'd have thought so21:55

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