public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "denisc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure
Date: Tue, 15 Nov 2011 16:43:00 -0000	[thread overview]
Message-ID: <bug-50775-4-hV2L3eFvyq@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50775-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50775

denisc at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denisc at gcc dot gnu.org,
                   |                            |vmakarov at redhat dot com

--- Comment #2 from denisc at gcc dot gnu.org 2011-11-15 16:32:58 UTC ---
Just a copy of my analysis from mailing list:

> Can anyone give me some advice how to proceed with this issue?
>
> Can be said if this is a target issue or IRA/reload flaw?

It's not a costs related problem.
I think that I can explain a problem.
I think that it's an IRA bug.

> Spilling for insn 11.
> Using reg 26 for reload 0
> Spilling for insn 17.
> Using reg 30 for reload 0
> Spilling for insn 23.
> Using reg 30 for reload 0
>       Try Assign 60(a6), cost=16000

Wrong thing starts here...
ira-color.c:4120 allocno_reload_assign (a, forbidden_regs);

> changing reg in insn 2
> changing reg in insn 9
> changing reg in insn 13
> changing reg in insn 19
>      Assigning 60(freq=4000) a new slot 0
> Register 60 now on stack.

Call trace:
allocno_reload_assign() -> assign_hard_reg() -> get_conflict_profitable_regs()

The `get_conflict_profitable_regs' calculates wrong `profitable_regs[1]'

(Special for Vladimir)
AVR is an 8 bits microcontroller.
The AVR has only 3 pointer registers X, Y, and Z with the
following addressing capabilities:
 *X, *X++, *--X             (R27:R26, call-clobbered)
 *Y, *Y++, *--Y, *(Y+const) (R28:R29, call-saved, frame pointer)
 *Z, *Z++, *--Z, *(Z+const) (R30:R31, call-clobbered)
Also, all modes larger than 8 bits should start in an even register.

So, `get_conflict_profitable_regs' trying to calculate two arrays:
  - profitable_regs[0] for first word of register 60(a6)
  - profitable_regs[1] for second word of register 60(a6)

Values of `profitable_regs':
(gdb) p print_hard_reg_set (stderr,profitable_regs[0] , 01)
 0-2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
$63 = void
(gdb) p print_hard_reg_set (stderr,profitable_regs[1] , 01)
 0-2 4 6 8 10 12 14 16 18 20 22 24 26 28 30

They are equal !
It's wrong because second word of register 60(a6) must be allocated to
odd register.


This is a wrong place in `get_conflict_profitable_regs':
...
  nwords = ALLOCNO_NUM_OBJECTS (a);
  for (i = 0; i < nwords; i++)
    {
      obj = ALLOCNO_OBJECT (a, i);
      COPY_HARD_REG_SET (conflict_regs[i],
             OBJECT_TOTAL_CONFLICT_HARD_REGS (obj));
      if (retry_p)
    {
      COPY_HARD_REG_SET (profitable_regs[i],
                 reg_class_contents[ALLOCNO_CLASS (a)]);
      AND_COMPL_HARD_REG_SET (profitable_regs[i],
                  ira_prohibited_class_mode_regs
                  [ALLOCNO_CLASS (a)][ALLOCNO_MODE (a)]);
-------------------------------------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^
    }

ALLOCNO_MODE (a) is a right mode for first word (word = 8bits register)
But it's wrong mode for second word of allocno.
Even more, ALLOCNO_MODE (a) is a right mode only for whole allocno.
If we want to spill/load/store separate parts(IRA objects) of allocno
we must use mode of each part(object).

`ira_prohibited_class_mode_regs' derived only from HARD_REGNO_MODE_OK.
So, the second word of 60(a6) permitted to any register after first
word of 60(a6).
For AVR: profitable_regs[1] = profitable_regs[0] << 1

Also, I have a question about the following fields of `ira_allocno':
  /* The number of objects tracked in the following array.  */
  int num_objects;
  /* An array of structures describing conflict information and live
     ranges for each object associated with the allocno.  There may be
     more than one such object in cases where the allocno represents a
     multi-word register.  */
  ira_object_t objects[2];
--------------------------^^^^^
The SImode for AVR consists of 4 words, but only 2 objects in allocno
structure.
Is this right ?

Denis.


  parent reply	other threads:[~2011-11-15 16:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18 11:44 [Bug other/50775] New: " gjl at gcc dot gnu.org
2011-10-18 12:08 ` [Bug other/50775] " gjl at gcc dot gnu.org
2011-10-25  9:48 ` gjl at gcc dot gnu.org
2011-11-15 16:43 ` denisc at gcc dot gnu.org [this message]
2011-11-15 16:49 ` denisc at gcc dot gnu.org
2011-11-28 22:10 ` vmakarov at redhat dot com
2011-11-29  0:16 ` gjl at gcc dot gnu.org
2011-12-04  4:09 ` vmakarov at redhat dot com
2011-12-05 17:03 ` vmakarov at gcc dot gnu.org
2011-12-05 18:16 ` law at redhat dot com
2011-12-15 19:10 ` gjl 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-50775-4-hV2L3eFvyq@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).