On Wed, Aug 21, 2019 at 01:50:52PM +0200, Christophe Leroy wrote: > Le 21/08/2019 à 13:44, Segher Boessenkool a écrit : > >Calls are cheap, in principle... It is the LR stuff that can make it > >slower on some cores, and a lot of calling sequence stuff may have > >considerable overhead of course. > > On an 8xx, a taken branch is 2 cycles and a non taken branch in 1 cycle > (+ the refetch if that was not the anticipate branch).
Yup. And on the big cores they are all 0 cycles, if correctly predicted. (Taken branches end your fetch group, of course, there are small inefficiencies everywhere, but that's about the gist of it). > >>+.macro get_datapage ptr, tmp > >>+ bcl 20,31,888f > >>+888: > >>+ mflr \ptr > >>+ addi \ptr, \ptr, __kernel_datapage_offset - 888b > >>+ lwz \tmp, 0(\ptr) > >>+ add \ptr, \tmp, \ptr > >>+.endm > > > >(You can just write that as > > bcl 20,31,$+4 > > mflr \ptr > >etc. Useless labels are useless :-) ) > > Nice trick. Will use that. Or .+4 if you like that syntax better... It's all the same thing. > >One thing you might want to do to improve performance is to do this without > >the bcl etc., because you cannot really hide the LR latency of that. But > >that isn't very many ns either... Superscalar helps, OoO helps, but it is > >mostly just that >100MHz helps ;-) > > Good idea. Did you have a look at my vdso32 similar patch ? > https://patchwork.ozlabs.org/patch/1148274/ Yes, I saw it. > Do you have any idea on how to avoid that bcl/mflr stuff ? Do a load from some fixed address? Maybe an absolute address, even? lwz r3,-12344(0) or similar (that address is in kernel space...) There aren't many options, and certainly not many *good* options! Segher