This is the mail archive of the
mailing list for the GCC project.
Re: RTL representation of i386 shrdl instruction is incorrect?
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Niranjan Hasabnis <nhasabni at cs dot stonybrook dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 5 Jun 2014 22:47:36 +0200 (CEST)
- Subject: Re: RTL representation of i386 shrdl instruction is incorrect?
- Authentication-results: sourceware.org; auth=none
- References: <CAD2ATQRUESv12+EDNmFRUt8jQfMVNuEz1UW9iv-5FMLOyiEYNw at mail dot gmail dot com> <49971e01659a40019e093d571dd29e99 at HUBCAS2 dot cs dot stonybrook dot edu> <CAD2ATQSx8Yye3CnbAB2OhXgNZwaB-4T3ym9FftdTJ-jBrdCbuQ at mail dot gmail dot com>
- Reply-to: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
On Thu, 5 Jun 2014, Niranjan Hasabnis wrote:
Thanks for your reply. I looked into some of the details of how that
particular RTL template is used. It seems to me that the particular
RTL template is used only when shifting 64-bit data type on a 32-bit
machine. This is the underlying assumption encoded in i386.c file
which generates that particular RTL only when instruction mode is
DImode. If that is the case, then it won't matter whether one uses
arithmetic shift or logical shift to right shift lower 4-bytes of a 8-byte
value. In other words, the mapping between RTL template and shrdl
is incorrect, but the underlying assumption in i386.c guards the bug.
This is still a bug, please file a PR. The use of (match_dup 0) apparently
prevents combine from matching the insn (that's just a guess from my notes
in PR 55583, I don't have access to my gcc machine right now to check),
but that doesn't mean we shouldn't fix things.