public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os
Date: Thu, 24 Sep 2015 20:38:00 -0000	[thread overview]
Message-ID: <bug-61578-4-c16ykUuKN1@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-61578-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #30 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Dominik Vogt from comment #29)
> I think I understand what's going on:
> 
> Consider the patched code in match_reloads():
> 
> +       = (ins[1] < 0 && REG_P (in_rtx)
> +          && (int) REGNO (in_rtx) < lra_new_regno_start
> +          && find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx))
> +          ? lra_create_new_reg (inmode, in_rtx, goal_class, "")
> +          : lra_create_new_reg_with_unique_value (outmode, out_rtx,
> +                                                  goal_class, ""));
> 
> (1) This code normally makes a unique copy of the register in in_rtx, but if
> the register is marked as REG_DEAD in the curr_insn, it just makes a copy of
> the register using lra_create_new_reg(), with the same .val and .offset in
> the reg_info structure.
> 
> (2) Further down in match_reloads, new insns are generated and stored in
> *before and *after.  However, the new "after" insn still references the old
> register.  In other words, in step (1) the code has made the assumption that
> the old register is no longer used, then generates an insn that uses it
> after it was marked as REG_DEAD.
> 
> (3) Based on the bogus decision in (1), the condition in lra-lives.c decides
> that the two registers are identical copies and can be mapped to the same
> hard register:
> 
> +         && (((src_regno >= FIRST_PSEUDO_REGISTER
> +               && (! sparseset_bit_p (pseudos_live, src_regno)
> +                   || (dst_regno >= FIRST_PSEUDO_REGISTER
> +                       && lra_reg_val_equal_p (src_regno,
> +                                               lra_reg_info[dst_regno].val,
> +                                              
> lra_reg_info[dst_regno].offset))

Sorry for breaking s390 port and thanks for the analysis.  I'll try to fix it
on this week.


  parent reply	other threads:[~2015-09-24 20:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-21 10:32 [Bug c/61578] New: " fredrik.hederstierna@securitas-direct.com
2014-06-21 10:33 ` [Bug c/61578] " fredrik.hederstierna@securitas-direct.com
2014-06-21 10:34 ` fredrik.hederstierna@securitas-direct.com
2014-06-21 10:34 ` fredrik.hederstierna@securitas-direct.com
2014-06-21 10:35 ` fredrik.hederstierna@securitas-direct.com
2014-06-21 10:35 ` fredrik.hederstierna@securitas-direct.com
2014-07-24 14:42 ` [Bug target/61578] " ramana at gcc dot gnu.org
2014-08-14 14:23 ` vmakarov at gcc dot gnu.org
2014-09-23 21:45 ` fredrik.hederstierna@securitas-direct.com
2014-11-02 20:35 ` fredrik.hederstierna@securitas-direct.com
2014-11-02 20:38 ` fredrik.hederstierna@securitas-direct.com
2014-11-03  1:33 ` zhenqiang.chen at arm dot com
2014-12-12 15:03 ` ramana at gcc dot gnu.org
2015-01-15 11:25 ` [Bug target/61578] [4.9/ 5 regression] " ramana at gcc dot gnu.org
2015-02-09  0:11 ` [Bug target/61578] [4.9/5 " pinskia at gcc dot gnu.org
2015-03-02 10:02 ` fredrik.hederstierna@securitas-direct.com
2015-03-03 16:05 ` law at redhat dot com
2015-06-26 19:57 ` [Bug target/61578] [4.9 " jakub at gcc dot gnu.org
2015-06-26 20:29 ` jakub at gcc dot gnu.org
2015-08-18 14:29 ` fredrik.hederstierna@securitas-direct.com
2015-08-18 14:41 ` fredrik.hederstierna@securitas-direct.com
2015-08-19 10:56 ` fredrik.hederstierna@securitas-direct.com
2015-09-01 14:06 ` vmakarov at gcc dot gnu.org
2015-09-01 14:16 ` fredrik.hederstierna@securitas-direct.com
2015-09-01 19:38 ` vmakarov at gcc dot gnu.org
2015-09-03  5:16 ` fredrik.hederstierna@securitas-direct.com
2015-09-03 14:59 ` vmakarov at gcc dot gnu.org
2015-09-08 21:38 ` fredrik.hederstierna@securitas-direct.com
2015-09-10 20:18 ` vmakarov at gcc dot gnu.org
2015-09-22 17:13 ` vogt at linux dot vnet.ibm.com
2015-09-22 17:41 ` vogt at linux dot vnet.ibm.com
2015-09-23 12:16 ` vogt at linux dot vnet.ibm.com
2015-09-24 20:38 ` vmakarov at gcc dot gnu.org [this message]
2015-09-24 20:41 ` vmakarov at gcc dot gnu.org
2015-09-25  9:12 ` vogt at linux dot vnet.ibm.com
2015-09-28  9:12 ` vogt at linux dot vnet.ibm.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-61578-4-c16ykUuKN1@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).