public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).