public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
Date: Tue, 05 Mar 2024 08:24:50 +0000	[thread overview]
Message-ID: <bug-114232-4-OghdQYJgO5@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114232-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Sam James from comment #0)

> (insn 160 159 161 26 (parallel [
>             (set (reg:V2QI 250 [ vect_patt_207.470_183 ])
>                 (minus:V2QI (reg:V2QI 251)
>                     (reg:V2QI 249 [ vect__4.468_451 ])))
>             (clobber (reg:CC 17 flags))
>         ])

This is the definition of the offending pattern in mmx.md:

(define_insn "<insn>v2qi3"
  [(set (match_operand:V2QI 0 "register_operand" "=?Q,x,Yw")
        (plusminus:V2QI
          (match_operand:V2QI 1 "register_operand" "<comm>0,0,Yw")
          (match_operand:V2QI 2 "register_operand" "Q,x,Yw")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
  "#"
  [(set_attr "isa" "*,sse2_noavx,avx")
   (set_attr "type" "multi,sseadd,sseadd")
   (set_attr "mode" "QI,TI,TI")])

where -march=i686 (aka pentiumpro) implies TARGET_PARTIAL_REG_STALL, so it
should be disabled unless optimizing for size. I wonder if
optimize_function_for_size_p is stable during the LTO compilation, but we have
plenty of usages like the above throughout x86  .md files and there were no
problems reported.

Another possibility is that the instruction RTX is emitted without checking of
the pattern condition, the testcase is compiled with -O3, so
optimize_function_for_size_p should also be false.

I don't see anything wrong with the above pattern. The failure also happens
very early into the RTL part of the compilation (vregs pass is the first pass
that tries to recognize the pattern), so my bet is on middle-end emitting insn
pattern without checking for pattern availability.

  parent reply	other threads:[~2024-03-05  8:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05  7:04 [Bug target/114232] New: " sjames at gcc dot gnu.org
2024-03-05  7:05 ` [Bug target/114232] " sjames at gcc dot gnu.org
2024-03-05  7:05 ` sjames at gcc dot gnu.org
2024-03-05  7:05 ` sjames at gcc dot gnu.org
2024-03-05  8:24 ` ubizjak at gmail dot com [this message]
2024-03-05  8:59 ` ubizjak at gmail dot com
2024-03-05  9:10 ` rguenth at gcc dot gnu.org
2024-03-05  9:12 ` rguenth at gcc dot gnu.org
2024-03-05  9:14 ` rguenth at gcc dot gnu.org
2024-03-05  9:53 ` ubizjak at gmail dot com
2024-03-05 10:30 ` ubizjak at gmail dot com
2024-03-05 10:36 ` rguenth at gcc dot gnu.org
2024-03-05 10:38 ` jakub at gcc dot gnu.org
2024-03-05 10:48 ` ubizjak at gmail dot com
2024-03-05 10:52 ` rguenther at suse dot de
2024-03-05 11:58 ` jakub at gcc dot gnu.org
2024-03-05 12:09 ` ubizjak at gmail dot com
2024-03-05 12:57   ` Jan Hubicka
2024-03-05 12:21 ` jakub at gcc dot gnu.org
2024-03-05 12:30 ` hubicka at ucw dot cz
2024-03-05 12:49 ` ubizjak at gmail dot com
2024-03-05 12:53 ` jakub at gcc dot gnu.org
2024-03-05 12:57 ` hubicka at ucw dot cz
2024-03-05 13:06 ` rguenther at suse dot de
2024-03-05 13:08 ` ubizjak at gmail dot com
2024-03-05 13:11 ` jakub at gcc dot gnu.org
2024-03-05 13:43 ` ubizjak at gmail dot com
2024-03-05 14:13 ` hubicka at ucw dot cz
2024-03-06  8:47 ` ubizjak at gmail dot com
2024-03-06 19:54 ` cvs-commit at gcc dot gnu.org
2024-03-06 20:10 ` ubizjak at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-114232-4-OghdQYJgO5@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).