public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "wilco at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
Date: Fri, 17 Apr 2020 10:23:59 +0000	[thread overview]
Message-ID: <bug-94538-4-lM8bMYRCYP@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94538-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #16 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #15)
> (In reply to Wilco from comment #14)
> > (In reply to Christophe Lyon from comment #11)
> > > (In reply to Wilco from comment #10)
> > 
> > > Right, but the code is functional.
> > 
> > It doesn't avoid the literal load from flash which is exactly what pure-code
> > and slow-flash-data is all about.
> 
> For f1 on M0, I can see:
>         .section        .rodata.cst4,"aM",%progbits,4
>         .align  2
> .LC0:
>         .word   .LANCHOR0
>         .section .text,"0x20000006",%progbits
> [...]
> f1:
>         movs    r3, #:upper8_15:#.LC0
>         lsls    r3, #8
>         adds    r3, #:upper0_7:#.LC0
>         lsls    r3, #8
>         adds    r3, #:lower8_15:#.LC0
>         lsls    r3, #8
>         adds    r3, #:lower0_7:#.LC0
>         ldr     r3, [r3]        @ 6     [c=10 l=2]  *thumb1_movsi_insn/8
>         ldr     r0, [r3]        @ 7     [c=10 l=2]  *thumb1_movsi_insn/8
>         bx      lr
> [...]
>         .bss
>         .align  2
>         .set    .LANCHOR0,. + 0
>         .type   x, %object
>         .size   x, 4
> x:
>         .space  4
> 
> So the 1st load is from .rodata.cst4 and the 2nd load is from bss, both of
> which do not have the purecode bit set (unlike .text). Isn't that OK?

No, it will create a lot of complaints and support queries due to the obvious
regressions. It goes against the definition of pure-code and slow-flash-data
which is to remove the literal loads. And given the sequence is already
inefficient, we should do everything to remove the indirection which increases
the codesize overhead by 75%...

Another aspect that needs to be checked is that GCC correctly spills addresses
and complex constants instead of rematerializing them. This is basic minimal
quality that one expects for a feature like this.

  parent reply	other threads:[~2020-04-17 10:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 11:02 [Bug target/94538] New: [9/10 " zsojka at seznam dot cz
2020-04-09 13:38 ` [Bug target/94538] " wilco at gcc dot gnu.org
2020-04-09 16:35 ` [Bug target/94538] [10 " wilco at gcc dot gnu.org
2020-04-09 17:46 ` zsojka at seznam dot cz
2020-04-09 18:08 ` wilco at gcc dot gnu.org
2020-04-10 23:42 ` cvs-commit at gcc dot gnu.org
2020-04-10 23:51 ` iains at gcc dot gnu.org
2020-04-14 11:28 ` wilco at gcc dot gnu.org
2020-04-14 12:16 ` clyon at gcc dot gnu.org
2020-04-14 12:54 ` zsojka at seznam dot cz
2020-04-14 14:42 ` wilco at gcc dot gnu.org
2020-04-14 17:08 ` clyon at gcc dot gnu.org
2020-04-16 15:40 ` clyon at gcc dot gnu.org
2020-04-16 16:44 ` wilco at gcc dot gnu.org
2020-04-16 17:10 ` wilco at gcc dot gnu.org
2020-04-16 19:41 ` clyon at gcc dot gnu.org
2020-04-17 10:23 ` wilco at gcc dot gnu.org [this message]
2020-04-30  7:27 ` [Bug target/94538] [9/10 " rguenth at gcc dot gnu.org
2020-04-30  9:44 ` clyon at gcc dot gnu.org
2020-04-30 12:28 ` wilco at gcc dot gnu.org
2020-08-24  9:09 ` [Bug target/94538] [9/10/11 " cvs-commit at gcc dot gnu.org
2020-08-24 13:32 ` clyon at gcc dot gnu.org
2020-08-27 11:12 ` cvs-commit at gcc dot gnu.org
2020-08-27 11:18 ` cvs-commit at gcc dot gnu.org
2020-08-27 11:19 ` clyon 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-94538-4-lM8bMYRCYP@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).