This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>
- Date: Wed, 16 Dec 2015 13:18:41 +0100
- Subject: Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition
- Authentication-results: sourceware.org; auth=none
- References: <566EB527 dot 6070305 at foss dot arm dot com> <56702223 dot 80702 at redhat dot com> <56703E12 dot 40705 at foss dot arm dot com>
On 12/15/2015 05:21 PM, Kyrill Tkachov wrote:
Then for the shift pattern in the MD file we'd have to dynamically
select the scheduling type depending on whether or not the shift
amount is 1 and the costs line up?
Yes. This isn't unusual, take a look at i386.md where you have a lot of
switches on attr type to decide which string to print.
The price we pay when trying these substitutions is an iteration over
the rtx with FOR_EACH_SUBRTX_PTR. recog gets called only if that
iteration actually performed a substitution of x + x into x << 1. Is
that too high a price to pay? (I'm not familiar with the performance
characteristics of the FOR_EACH_SUBRTX machinery)
It depends on how many of these transforms we are going to try; it also
feels very hackish, trying to work around the core design of the
combiner. IMO it would be better for machine descriptions to work with
the pass rather than against it.
If you can somehow arrange for the (plus x x) to be turned into a shift
while substituting that might be yet another approach to try.
Bernd