This is the mail archive of the
mailing list for the GCC project.
Re: combine_simplify_rtx (doesn't) commute XOR and ASHIFTRT ???
- From: Alan Lawrence <alan dot lawrence at arm dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "law at redhat dot com" <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 30 Jun 2014 20:20:38 +0100
- Subject: Re: combine_simplify_rtx (doesn't) commute XOR and ASHIFTRT ???
- Authentication-results: sourceware.org; auth=none
- References: <53A98028 dot 2000604 at arm dot com> <53A9B28E dot 80803 at redhat dot com> <20140624212633 dot D1DC033C9D at vlsi1 dot gnat dot com>
Thanks for the quick response - the possibility of different modes seems
plausible, as I'm not sure what would happen in that case. (Although I'm not
entirely sure how that case would occur - something that may have changed since
the original.) I haven't had much luck in getting a working toolchain from 2004,
so I've gone with the approach of preserving the check if result_mode !=
shift_mode, as per patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02426.html .
Richard Kenner wrote:
I haven't heard from Kenner in a while, but you could always try to
contact him directly and see if he can recall the issue. It was a long
time ago though...
and wondering if anyone can explain to me what's wrong with this
transformation. Having worked through all four cases of A and C1
positive and negative, it seems to me that the extra bits 'fed in' to
the most-significant end of the result are the same either way (i.e. the
XOR of the sign bits of A and C1).
I haven't gone anywhere ...
But indeed ten years is a long time and I don't have any recollection of
this at all. The above analysis seems right, but this isn't the sort of
thing I'd have done if there weren't some sort of bug. Perhaps it's only
relevant if result_mode != shift_mode?