This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Tighten memory type assumption in RTL combiner pass.
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Venkataramanan Kumar <venkataramanan dot kumar at linaro dot org>, rth at redhat dot com, "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, segher at kernel dot crashing dot org, Richard Earnshaw <rearnsha at arm dot com>, bernds at codesourcery dot com
- Date: Wed, 06 May 2015 08:32:13 +0100
- Subject: Re: [RFC] Tighten memory type assumption in RTL combiner pass.
- Authentication-results: sourceware.org; auth=none
- References: <CAJK_mQ3R90TsoKhoA5WMkPjn31UO8bkqc5Bwhaj9t+SyQ982Cg at mail dot gmail dot com> <54B6E243 dot 7040404 at redhat dot com> <CAJK_mQ3OyM78MsG45X8U2JbLU6UQFJcLD=u4RbREGFD9A587og at mail dot gmail dot com> <55398ACA dot 5090802 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 01/16/2015 12:13 AM, Venkataramanan Kumar wrote:
>>
>> The below test case which I am working on is from the PR63949
>>
>> int subsi_sxth (int a, short i)
>> {
>> /* { dg-final { scan-assembler "sub\tw\[0-9\]+,.*sxth #?1" } } */
>> return a - ((int)i << 1);
>> }
>>
>> The expression "a - ((int)i << 1)" is not a memory expression.
>> But combiner assumes that MINUS RTX as memory, and process all RTX
>> sub expressions with the memory assumption.
> Coming back to this old thread.
>
> And presumably when it treats this expression as a MEM, then we do the
> usual canonicalizations of turning ASHIFT into a MULT when we wanted to
> keep the code as an ASHIFT, right?
>
> The code in question comes from 1992:
>
> Fri Jun 26 07:06:19 1992 Richard Kenner (kenner@vlsi1.ultra.nyu.edu)
>
> [ ... ]
>
>
> * combine.c (make_compound_operation): Treat PLUS and MINUS
> the same when passing down the code to the next level; for
> consistency, an ASHIFT inside either gets turned into a MULT.
>
> Sadly, in that era of development, we didn't require nearly as many
> testcases as we do now. Similarly patches didn't have to be posted with
> a rationale for the patch. I've checked my gcc2 archives just to be
> sure and there's nothing about this patch in them.
>
> From reading the actual patch Kenner installed, I'm confident this was
> not a correctness issue, but instead was trying to improve the quality
> of the combiner output.
>
> So I think you've got a couple paths forward. First you could remove
> the PLUS/MINUS special casing and then verify nothing changes across a
> few targets (x86_64, ppc64, AArch64 would be my recommendations). And
> by nothing changes, I mean the assembly before/after is the same for all
> the files in a bootstrap. It's a fairly high hurdle.
>
> Alternately, you could find a way to accurately track if we're inside a
> MEM, where we want to canonicalize things slightly differently. Once we
> can accurately track if we're inside a MEM, then we no longer have to
> have the hack for PLUS/MINUS.
A third even higher hurdle would be to remove the idea that the
canonical form of an expression depends on whether it's in a MEM
or not. It just causes confusion when an lea is created from an
existing MEM address.
:-)
Richard