This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: combine_simplify_rtx (doesn't) commute XOR and ASHIFTRT ???


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 .

Thanks!
--Alan

Richard Kenner wrote:
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 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...

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?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]