On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: > > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote: > >> on 2022/10/26 19:40, Jiufu Guo wrote: > >> for "li/lis + oris/xoris", I interpreted it into four combinations: > >> > >> li + oris, lis + oris, li + xoris, lis + xoris. > >> > >> not sure just me interpreting like that, but the actual combinations > >> which this patch adopts are: > >> > >> li + oris, li + xoris, lis + xoris. > >> > >> It's a bit off, but not a big deal, up to you to reword it or not. :) > > > > The first two are obvious, but the last one is almost never a good idea, > > there usually are better ways to do the same. I cannot even think of > > any case where this is best? A lis;rl* is always prefered (it can > > optimise better, be combined with other insns). > I understant your point here. The first two: 'li' for lowest 16bits, > 'oris/xoris' for next 16bits. > > While for 'lis + xoris', it may not obvious, because both 'lis' and > 'xoris' operates on 17-31bits. > 'lis + xoris' is for case "32(1) || 1(0) || 15(x) || 16(0)". xoris is > used to clean bit31. This case seems hard to be supported by 'rlxx'.
Please put that in a separate patch? First do a patch with just lis;x?oris. They are unrelated and different in almost every way. > I hit to find this case when I analyze what kind of constants can be > build by two instructions. Checked the posssible combinations: > "addi/addis" + "neg/ori/../xoris/rldX/rlwX/../sradi/extswsli"(those > instructions which accept one register and one immediate). > > I also drafted the patch to use "li/lis+rlxx" to build constant. > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601276.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601277.html Those seem to do many things in one patch as well :-( It is very hard to review such things, it takes many hours each to do properly. Segher
