Thread (10 messages) 10 messages, 4 authors, 2019-03-31

Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?

From: Segher Boessenkool <hidden>
Date: 2019-03-30 23:53:58
Also in: linux-alpha, linux-mips

On Sat, Mar 30, 2019 at 11:28:21AM +0000, George Spelvin wrote:
quoted
quoted
I like that the MIPS code leaves the high half of the product in
the hi register until it tests the low half; I wish PowerPC would
similarly move the mulhdu *after* the loop,
quoted
The MIPS code has the multiplication inside the loop as well, and even
the mfhi I think: MIPS has delay slots.
Yes, it's in the delay slot, which is fine (the branch is unlikely,
after all).  But it does the compare (sltu) before accessing %hi, which
is good as %hi often has a longer latency than %lo.  (On out-of-order
cores, of course, none of this matters.)
Yes.  But it does the mfhi on every iteration, while it only needs it for
the last one (or after the last one).  This may not be more expensive for
the actual hardware, but it is for GCC's cost model
quoted
GCC treats the int128 as one register until it has expanded to RTL, and it
does not do such loop optimisations after that, apparently.

File a PR please?  https://gcc.gnu.org/bugzilla/
Er...  about what?  The fact that the PowerPC code is not
quoted
quoted
PowerPC:
.L9:
	bl get_random_u64
	nop
	mulld 9,3,31
	cmpld 7,30,9
	bgt 7,.L9
	mulhdu 3,3,31
I'm not sure quite how to explain it in gcc-ese.
Yeah, exactly, like that.  This transformation is called "loop sinking"
usually: if anything that is set within a loop is only used after the loop,
it can be set after the loop (provided you keep the set's sources alive).


Segher
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help