https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118608

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle <roger at nextmovesoftware dot com> ---
Created attachment 60401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60401&action=edit
proposed patch

Here's my proposed solution to this issue (which requires three independent
tweaks, one in each source file).  The first tweak is that the logic in my
original patch for determining whether store_field updates the most significant
bit needs to be updated to handle BYTES_BIG_ENDIAN.  Of the two insertions in
bugzilla testcase, we were generating the sign extension after the wrong one. 
The second tweak was that this explicit sign-extension was then being
eliminated during combine by simplify-rtx that believed the explicit TRUNCATE
wasn't required.  This patch updates truncated_to_mode to understand that on
mode_rep_extended targets, TRUNCATE is used instead of SUBREG because it really
is required.  Finally, the third tweak is that the MIPS backend requires a
small change to recognize (and split) *extenddi_truncatesi when TARGET_64BIT
and !ISA_HAS_EXTS.

On mips64-elf with -mabi=64 the following are now generated for prepareNeedle:

-O2
        sll     $5,$5,16
        jr      $31
        or      $2,$5,$4

-Os
        dsll    $5,$5,16
        or      $2,$4,$5
        dsll    $2,$2,32
        jr      $31
        dsra    $2,$2,32

-O2 -march=octeon2
        move    $2,$0
        ins     $2,$5,16,16
        jr      $31
        ins     $2,$4,0,16

-Os -march=octeon2
        move    $2,$0
        dins    $2,$4,0,16
        dins    $2,$5,16,16
        jr      $31
        sll     $2,$2,0

Beyond building cc1 for mips64-elf, this patch is completely untested.

If someone could please confirm that this fixes the wrong-code regression on
mips64 hardware (or a simulator), it would then be good to confirm that the
middle-end changes don't cause any (additional) problems on other targets.  The
combination of targetm.mode_rep_extended and BYTES_BIG_ENDIAN hopefully make
this issue rare.

Sorry for the inconvenience, and thanks in advance for any help.

Reply via email to