public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/94341] New: mve_mov can produce ICE on latest trunk
@ 2020-03-26 11:18 matmal01 at gcc dot gnu.org
  2020-03-26 11:21 ` [Bug target/94341] " matmal01 at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: matmal01 at gcc dot gnu.org @ 2020-03-26 11:18 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 94341
           Summary: mve_mov can produce ICE on latest trunk
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: sripar01 at gcc dot gnu.org
          Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---

The following code ICE's on fsf-trunk.

#include "arm_mve.h"

uint8x16_t test()
{
  uint8x16_t accum = (uint8x16_t)(uint32x4_t){0, 0, 0, 2};
  uint8x16_t accum2 = (uint8x16_t)(uint32x4_t){0, 0, 0, 1};
  accum += __arm_vddupq_m_n_u8 (accum2, 0, 4, (mve_pred16_t)1);
  return accum;
}


It ICE's because the first (define_insn "*mve_mov<mode>" ...)  pattern has the
following clause for it's 4th alternative:

    case 4:
      if ((TARGET_HAVE_MVE_FLOAT && VALID_MVE_SF_MODE (<MODE>mode))
          || (MEM_P (operands[1])
              && (GET_CODE (XEXP (operands[1], 0)) == LABEL_REF)))
        return output_move_neon (operands);
      else
        return "vldrb.8 %q0, %E1";



For the test above, we get an RTL pattern of

(insn 5 7 6 2 (set (reg:V16QI 28 s12 [116])
        (mem:V16QI (const:SI (plus:SI (label_ref 28)
                    (const_int 16 [0x10]))) [0  S16 A64]))
"cde-mve-tests.c":6:12 2990 {*mve_movv16qi}
     (expr_list:REG_EQUIV (const_vector:V16QI [
                (const_int 0 [0]) repeated x16
            ])
        (nil)))


This matches the *mve_movv16qi pattern on the fourth alternative.
the clause above does not match for going into `output_move_neon` (since the
operand is not a mem of a label_ref, it's the mem of an offset to a label_ref).

Hence the compiler tries to emit "vldrb.8 %q0, %E1", but since the 'E' syntax
is for registers it does not match the RTL pattern for the operand.
This results in an ICE.


test:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        mov     r3, #1  @ movhi
        movs    r2, #0
        vldr.64 d6, .L3
        vldr.64 d7, .L3+8
during RTL pass: final
dump file: cde-mve-tests.c.314r.final
/home/matmal01/Documents/gnu-work/cde-intrinsics/cde-mve-tests.c: In function
'test':
/home/matmal01/Documents/gnu-work/cde-intrinsics/cde-mve-tests.c:9:1: internal
compiler error: in arm_print_operand, at config/arm/arm.c:23953
0x113c138 arm_print_operand
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/config/arm/arm.c:23953
0x9332c5 output_operand(rtx_def*, int)
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4051
0x933b63 output_asm_insn(char const*, rtx_def**)
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3944
0x9366b6 final_scan_insn_1
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3106
0x9369a7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:3152
0x9376ac final_1
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:2020
0x9378f6 rest_of_handle_final
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4658
0x9378f6 execute
       
/tmp/dgboter/bbs/rhev-vm10--rhe6x86_64/buildbot/rhe6x86_64--arm-none-eabi/build/src/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
        vldrb.8 q0, gcc [11:11:19] $

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/94341] mve_mov can produce ICE on latest trunk
  2020-03-26 11:18 [Bug target/94341] New: mve_mov can produce ICE on latest trunk matmal01 at gcc dot gnu.org
@ 2020-03-26 11:21 ` matmal01 at gcc dot gnu.org
  2020-04-09 12:15 ` sripar01 at gcc dot gnu.org
  2020-04-09 12:16 ` sripar01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: matmal01 at gcc dot gnu.org @ 2020-03-26 11:21 UTC (permalink / raw)
  To: gcc-bugs

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

Matthew Malcomson <matmal01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-03-26
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Matthew Malcomson <matmal01 at gcc dot gnu.org> ---
Have already discussed bug privately and work is being done on it.

Just posting this so I have a public page for reference in public discussions.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/94341] mve_mov can produce ICE on latest trunk
  2020-03-26 11:18 [Bug target/94341] New: mve_mov can produce ICE on latest trunk matmal01 at gcc dot gnu.org
  2020-03-26 11:21 ` [Bug target/94341] " matmal01 at gcc dot gnu.org
@ 2020-04-09 12:15 ` sripar01 at gcc dot gnu.org
  2020-04-09 12:16 ` sripar01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: sripar01 at gcc dot gnu.org @ 2020-04-09 12:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from SRINATH PARVATHANENI <sripar01 at gcc dot gnu.org> ---
Patch committed by Andre:

commit b094133c1c5bf21ccd60c344de6f4a798140e61b
Author: Andre Simoes Dias Vieira <andre.simoesdiasvieira@arm.com>
Date:   Tue Apr 7 13:36:43 2020 +0100

    arm: MVE: Fix constant load pattern

    This patch fixes the constant load pattern for MVE, this was not accounting
    correctly for label + offset cases.

    Added test that ICE'd before and removed the scan assemblers for the
mve_vector*
    tests as they were too fragile.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug target/94341] mve_mov can produce ICE on latest trunk
  2020-03-26 11:18 [Bug target/94341] New: mve_mov can produce ICE on latest trunk matmal01 at gcc dot gnu.org
  2020-03-26 11:21 ` [Bug target/94341] " matmal01 at gcc dot gnu.org
  2020-04-09 12:15 ` sripar01 at gcc dot gnu.org
@ 2020-04-09 12:16 ` sripar01 at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: sripar01 at gcc dot gnu.org @ 2020-04-09 12:16 UTC (permalink / raw)
  To: gcc-bugs

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

SRINATH PARVATHANENI <sripar01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #3 from SRINATH PARVATHANENI <sripar01 at gcc dot gnu.org> ---
Fixed

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-04-09 12:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-26 11:18 [Bug target/94341] New: mve_mov can produce ICE on latest trunk matmal01 at gcc dot gnu.org
2020-03-26 11:21 ` [Bug target/94341] " matmal01 at gcc dot gnu.org
2020-04-09 12:15 ` sripar01 at gcc dot gnu.org
2020-04-09 12:16 ` sripar01 at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).