[PATCH] middle-end: Recognize/canonicalize MULT_HIGHPART_EXPR and expand it.

Roger Sayle roger@nextmovesoftware.com
Tue Aug 4 12:17:36 GMT 2020

This middle-end patch teaches fold/match to recognize the idiom for
a highpart multiplication and represent it internally as a
MULT_HIGHPART_EXPR tree code.  At RTL expansion time, the compiler
will trying using an appropriate instruction (sequence) provided
by the backend, but if that fails, this patch now provides a fallback
by synthesizing a suitable sequence using either a widening multiply
or a multiplication in a wider mode [matching the original tree].

The benefit of this internal canonicalization is that it allows GCC
to generate muldi3_highpart instructions even on targets that require
a libcall to perform TImode multiplications.  Currently the RTL
optimizers can recognize highpart multiplications in combine, but
this matching fails when the multiplication requires a libcall.
Rather than attempt to do something via REG_EQUAL_NOTEs, a clever
solution is to make more use of the MULT_HIGHPART_EXPR tree code
in the tree optimizers.

This patch has been tested on x86_64-pc-linux-gnu with a "make
bootstrap" and "make -k check", and on nvptx-none with a "make"
and "make -k check", both with no few failures.  There's an
additional target-specific test in the nvptx patch to support
"mul.hi.s64" and "mul.hi.u64" that I'm just about to post, but
this code is already well exercised during bootstrap by libgcc.

Ok for mainline?

2020-08-04  Roger Sayle  <roger@nextmovesoftware.com>

	* match.pd (((wide)x * (wide)y)>>C -> mult_highpart): New
	simplification/canonicalization to recognize MULT_HIGHPART_EXPR.
	* optabs.c (expand_mult_highpart_1): New function to expand
	MULT_HIGHPART_EXPR as a widening or a wide multiplication
	followed by a right shift (or a gen_highpart subreg).
	(expand_mult_highpart): Call the above function if the target
	doesn't provide a suitable optab.

	* gcc.dg/fold-mult-highpart-1.c: New test.

Thanks in advance,
Roger Sayle
NextMove Software
Cambridge, UK

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patcha4b.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200804/0aa73ce9/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patcha4c.txt
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200804/0aa73ce9/attachment-0003.txt>

More information about the Gcc-patches mailing list