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
next prev parent 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).