From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gcc@gcc.gnu.org, jh@suse.cz, Jeffrey A Law <law@redhat.com>
Subject: Re: Non-representable subregs of subword pseudoregs
Date: Sat, 13 Nov 2004 20:24:00 -0000 [thread overview]
Message-ID: <200411132022.41562.ebotcazou@libertysurf.fr> (raw)
In-Reply-To: <200411131839.iADId4ht001145@53v30g15.boeblingen.de.ibm.com>
> (I assume this has word_mode == DImode?)
Of course. Sorry for not explicitly mentioning it.
> While there's unfortunately some amount of confusion as to which
> subregs are valid, exactly, I think it should be pretty clear
> that *this* subreg is certainly *not* valid.
>
> As per the documentation, subregs can be used to denote either
> - a value re-interpreted in another mode (this always means lowpart)
> or
> - one of the words of a multi-word value (i.e. > word_mode)
> or
> - a combination of the two (a lowpart of one word of a multi-word)
>
> Since (reg:DI 126) is a single-word value, and the subreg does
> not denote the lowpart, it should be invalid.
I think this makes sense. But take a look at gen_realpart:
if (WORDS_BIG_ENDIAN
&& GET_MODE_BITSIZE (mode) < BITS_PER_WORD
&& REG_P (x)
&& REGNO (x) < FIRST_PSEUDO_REGISTER)
internal_error
("can't access real part of complex value in hard register");
else if (WORDS_BIG_ENDIAN)
return gen_highpart (mode, x);
else
return gen_lowpart (mode, x);
You can't help but thinking that whoever wrote the check thought that highpart
subregs of subword pseudo regs were valid. It turns out that Jeff added it
in rev. 1.62 of emit-rtl.c.
Jeff, what's your take on this?
--
Eric Botcazou
next prev parent reply other threads:[~2004-11-13 19:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-13 19:24 Ulrich Weigand
2004-11-13 20:24 ` Eric Botcazou [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-11-13 13:17 Eric Botcazou
2004-11-13 13:45 ` Jan Hubicka
2004-11-13 22:55 ` Richard Sandiford
2004-11-13 23:31 ` Eric Botcazou
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=200411132022.41562.ebotcazou@libertysurf.fr \
--to=ebotcazou@libertysurf.fr \
--cc=gcc@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=law@redhat.com \
--cc=uweigand@de.ibm.com \
/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).