public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Jan Hubicka <jh@suse.cz>, gcc@gcc.gnu.org
Subject: Re: Reload bug
Date: Thu, 10 Apr 2003 20:43:00 -0000	[thread overview]
Message-ID: <20030410202612.GI9319@kam.mff.cuni.cz> (raw)
In-Reply-To: <200304102200.35188.ebotcazou@libertysurf.fr>

> > I think you're completely right: the reload pass has no specific
> > infrastructure for dealing with invalid subregs. It may "fix" these
> > subregs, but only if it happens that the operand needs reloading because
> > of the insn constraints.
> 
> I've found why: the code has been disabled in find_reloads()
> 
> 		  /* This following hunk of code should no longer be
> 		     needed at all with SUBREG_BYTE.  If you need this
> 		     code back, please explain to me why so I can
> 		     fix the real problem.  -DaveM */
> #if 0
> 		  /* Subreg of a hard reg which can't handle the subreg's mode
> 		     or which would handle that mode in the wrong number of
> 		     registers for subregging to work.  */
> 		  || (GET_CODE (operand) == REG
> 		      && REGNO (operand) < FIRST_PSEUDO_REGISTER
> 		      && ((GET_MODE_SIZE (operand_mode[i]) <= UNITS_PER_WORD
> 			   && (GET_MODE_SIZE (GET_MODE (operand))
> 			       > UNITS_PER_WORD)
> 			   && ((GET_MODE_SIZE (GET_MODE (operand))
> 				/ UNITS_PER_WORD)
> 			       != HARD_REGNO_NREGS (REGNO (operand),
> 						    GET_MODE (operand))))
> 			  || ! HARD_REGNO_MODE_OK (REGNO (operand) + offset,
> 						   operand_mode[i])))
> #endif
> 
> Re-enabling it fix PR target/10286.
> 
> Now the question: what is the replacement machinery that is supposed to be 
> doing the work?

Hmm, I've wondered about this piece of code as well today in the train.
I think Davej was wrong to disable it without approripate replacement.
The code is wrong for post-SUBREG_BYTE patch as it checks that the
partial regs have exactly size of one word, but we do allow subregs on
registers of different sizes.  We need to verify that offset can
represent the register exactly.

Looking as subreg_regno_offset, I think we need to practically check
that division in:
  return (y_offset / (mode_multiple / nregs_multiple)) * nregs_ymode;
Does not round.  When it rounds we are having registers too wide and we
must reload.
All the other divisions should be safe from SUBREG definition that is
already verified by my simplify_subreg code.
We also should add a trap to subreg_regno_offset in the mainline...
Seems to make sense?

Honza

  reply	other threads:[~2003-04-10 20:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-08 18:52 Eric Botcazou
2003-04-08 23:16 ` Jan Hubicka
2003-04-09  0:44   ` Jan Hubicka
2003-04-09  7:00     ` Eric Botcazou
2003-04-09  3:00   ` Eric Botcazou
2003-04-09  9:49     ` Jan Hubicka
2003-04-09  8:57   ` Eric Botcazou
2003-04-09  9:45     ` Jan Hubicka
2003-04-09  9:50       ` Eric Botcazou
2003-04-09 14:52         ` Jan Hubicka
2003-04-09 18:10           ` Eric Botcazou
2003-04-09 19:15             ` Jan Hubicka
2003-04-10 14:25           ` Eric Botcazou
2003-04-10 16:31             ` Jan Hubicka
2003-04-10 16:35               ` Jan Hubicka
2003-04-10 20:21             ` Eric Botcazou
2003-04-10 20:43               ` Jan Hubicka [this message]
2003-04-11 14:44                 ` Eric Botcazou
2003-04-11 17:49                   ` Jan Hubicka
2003-04-11 18:09                   ` Jan Hubicka
2003-04-11 19:01                   ` Jan Hubicka
2003-04-11 19:07                   ` Jan Hubicka
2003-04-12 14:55                     ` Eric Botcazou
2003-04-12 17:45                       ` Jan Hubicka
2003-04-13 19:57                         ` Eric Botcazou
2003-04-13 20:04                           ` Jan Hubicka
2003-04-12 17:55                       ` Make reload to avoid invalid subregs Jan Hubicka
2003-04-17 22:32                         ` Richard Henderson
2003-04-10 20:51               ` Reload bug Dale Johannesen
2003-04-09  9:13 ` Eric Botcazou
2003-04-09 11:25   ` Jan Hubicka
2003-04-09 12:04     ` Eric Botcazou
2003-04-09 18:05       ` Jan Hubicka
2003-04-09 18:26         ` Eric Botcazou
2003-04-09 21:23         ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
1999-09-01  8:40 Andreas Schwab
1999-09-02  0:32 ` Jeffrey A Law
1999-09-02  2:15   ` Andreas Schwab
1999-09-30 18:02     ` Andreas Schwab
1999-09-30 18:02   ` Jeffrey A Law
1999-09-30 18:02 ` Andreas Schwab

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=20030410202612.GI9319@kam.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=ebotcazou@libertysurf.fr \
    --cc=gcc@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).