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 (ken...@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.
Jeff
