Wednesday, 2021-03-10

programmerjake[mlkcl: i think svp64 instructions without any vector arguments *should* be not dependent on VL==0 or not, they are used for purely scalar operations and are needed to access out-of-32-bit-range registers.00:11
programmerjake[mafter all, svp64 != vector instruction00:11
lxoprogrammerjake[m, that's my reasoning as well00:57
lxolkcl's reasoning makes sense as well, but I'll have to rethink how to implement scalar moves involving the extended svp registers00:59
lxosince their behavior will be affected by VL, it will have to be another input operand of pretty much every instruction01:01
programmerjake[mthis is just the latest instance of the trap of "scalar is just vector element 0" -- scalar really *should be* a totally different kind of thing than vector01:07
programmerjake[mand svp64 should not automatically mean vector01:08
programmerjake[mI guess you can summarize what I envision for svp64 as: prefix for accessing stuff added with SV. one of the features is vector operation, another independent feature is accessing registers > r31, another one is predication, and so on.01:14
programmerjake[musing svp64 doesn't automatically enable everything always, so why should vector/scalar be any different?01:15
programmerjake[mor, at least svp64 shouldn't automatically enable everything, all it does is provide the instruction fields with which all the new features can be independently enabled01:17
lxoprogrammerjake[m, or we could market svp64 as adding millions of new forms of nop ;-D01:41
programmerjake[mbut powerpc already has millions of nops...guess it never hurt anyone to add more :P01:42
programmerjake[mkinda like x86 has all the nops from 1 to 15 bytes long01:42
lxomake sv.nop generate a random svp64-prefixed insn, for better code obfuscation01:43
lxois setvli an svp64 insn, or is it not?01:45
lxoas in, after setting vl=0, can setvli still have any effect, or do you have to reset the processor to get out of the sv.nop mode?01:47
programmerjake[msetvl[i] would be a non-svp instruction, but now I'm wishing it was a svp instruction just to prove my point :P01:50
lkcl_cesar[m]2, yes scalar identity is identical... as long as VL=1.13:46
lkcl_there are going to be some permutations that quotes "do not make sense" quotes and there is nothing that can be done about that without also creating hardware-level decode dependencies that would absolutely kill the entire project stone dead13:47
lkcl_i added setvl to context-propagation
lkcl_context-propagation is a second phase which should reduce the impact of prefixing15:48
lkcl_hilariously it's possible to also add the v3.1 64-bit prefixes to the same table15:48
lkcl_i am not sure if context-propagation of setvl info will actually result in reduction of executable size though.15:49
lkcl_have to see how that goes15:49
lkcl_lxo: setvl - of which setvli is a pseudo-op constructed from setvl - is a 32-bit only instruction.16:45
lkcl_vl=0 converting all vector operations to NOPs is exactly how RVV operates, exactly how Cray Supercomputers have always operated.16:47
programmerjake[mone of the other reasons for wanting SVP64 scalar instructions is from a sense of math purity -- 1D tensors (ISA-level/compiler-level vectors) and scalars are 2 different kinds of math object, they should not be conflated. Also, having SVP64 scalars maps much more nicely to the compiler-IR-level, since that also has separate scalar and vector types.18:33
lxomeeting in 10', right?20:50
lxoI'm preparing to get thoroughly confused by DST changes in the Northern hemisphere :-)20:51

Generated by 2.17.1 by Marius Gedminas - find it at!