public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/113415] ICE: RTL check:  -mstringop-strategy=byte_loop vs inline-asm  goto with block copies
Date: Fri, 09 Feb 2024 10:09:20 +0000	[thread overview]
Message-ID: <bug-113415-4-PmyYGLb93x@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113415-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0ad1884089c0fad4dfc72516bc68ec508cba1832

commit r14-8896-g0ad1884089c0fad4dfc72516bc68ec508cba1832
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 9 11:08:33 2024 +0100

    expand: Fix asm goto expansion [PR113415]

    The asm goto expansion ICEs on the following testcase (which normally
    is rejected later), because expand_asm_stmt emits the code to copy
    the large var out of the out operand to its memory location into
    after_rtl_seq ... after_rtl_end sequence and because it is asm goto,
    it duplicates the sequence on each successor edge of the asm goto.
    The problem is that with -mstringop-strategy=byte_loop that sequence
    contains loops, so CODE_LABELs, JUMP_INSNs, with other strategies
    could contain CALL_INSNs etc.
    But the copying is done using a loop doing
    emit_insn (copy_insn (PATTERN (curr)));
    which does the right thing solely for INSNs, it will do the wrong thing
    for JUMP_INSNs, CALL_INSNs, CODE_LABELs (with RTL checking even ICE on
    them), BARRIERs and the like.

    The following patch partially fixes it (with the hope that such stuff only
    occurs in asms that really can't be accepted; if one uses say "=rm" or
    "=g" constraint then the operand uses the memory directly and nothing is
    copied) by using the
    duplicate_insn_chain function which is used e.g. in RTL loop unrolling and
    which can handle JUMP_INSNs, CALL_INSNs, BARRIERs etc.
    As it is meant to operate on sequences inside of basic blocks, it doesn't
    handle CODE_LABELs (well, it skips them), so if we need a solution that
    will be correct at runtime here for those cases, we'd need to do further
    work (e.g. still use duplicate_insn_chain, but if we notice any
CODE_LABELs,
    walk the sequence again, add copies of the CODE_LABELs and then remap
    references to the old CODE_LABELs in the copied sequence to the new ones).
    Because as is now, if the code in one of the sequence copies (where the
    CODE_LABELs have been left out) decides to jump to such a CODE_LABEL, it
    will jump to the CODE_LABEL which has been in the original sequence (which
    the code emits on the last edge, after all, duplicating the sequence
    EDGE_COUNT times and throwing away the original was wasteful, compared to
    doing that just EDGE_COUNT - 1 times and using the original.

    2024-02-09  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/113415
            * cfgexpand.cc (expand_asm_stmt): For asm goto, use
            duplicate_insn_chain to duplicate after_rtl_seq sequence instead
            of hand written loop with emit_insn of copy_insn and emit original
            after_rtl_seq on the last edge.

            * gcc.target/i386/pr113415.c: New test.

  parent reply	other threads:[~2024-02-09 10:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16  5:46 [Bug rtl-optimization/113415] New: ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1511 with -mstringop-strategy=byte_loop and invalid __asm__ on _BitInt() zsojka at seznam dot cz
2024-01-16  6:00 ` [Bug middle-end/113415] " pinskia at gcc dot gnu.org
2024-01-16  6:07 ` [Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies pinskia at gcc dot gnu.org
2024-01-18 23:03 ` pinskia at gcc dot gnu.org
2024-01-18 23:05 ` pinskia at gcc dot gnu.org
2024-02-07 21:33 ` pinskia at gcc dot gnu.org
2024-02-08 17:54 ` jakub at gcc dot gnu.org
2024-02-09 10:09 ` cvs-commit at gcc dot gnu.org [this message]
2024-02-09 10:13 ` jakub at gcc dot gnu.org
2024-02-14 17:25 ` pinskia at gcc dot gnu.org

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-113415-4-PmyYGLb93x@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).