public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@nildram.co.uk>
To: Ian Lance Taylor <iant@google.com>
Cc: Kenneth Zadeck <zadeck@naturalbridge.com>,
		  gcc-patches <gcc-patches@gcc.gnu.org>, 	  "Bonzini\,
	Paolo" <bonzini@gnu.org>
Subject: Re: [trunk] Addition to subreg section of rtl.text.
Date: Fri, 14 Mar 2008 15:17:00 -0000	[thread overview]
Message-ID: <87bq5hz6vs.fsf@firetop.home> (raw)
In-Reply-To: <m3od9hqs00.fsf@google.com> (Ian Lance Taylor's message of "Fri\, 14 Mar 2008 07\:50\:39 -0700")

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> Richard Sandiford wrote:
>> Kenneth Zadeck <zadeck@naturalbridge.com> writes:
>>> Does every one agree that what i am adding is correct?
>>>
>>> kenny
>>> Index: rtl.texi
>>> ===================================================================
>>> --- rtl.texi	(revision 133159)
>>> +++ rtl.texi	(working copy)
>>> @@ -1730,15 +1730,21 @@ are in @var{m}.
>>>  Sometimes @var{m} is wider than the mode of @var{reg}.  These
>>>  @code{subreg} expressions are often called @dfn{paradoxical}.  They are
>>>  used in cases where we want to refer to an object in a wider mode but do
>>> -not care what value the additional bits have.  The reload pass ensures
>>> -that paradoxical references are only made to hard registers.
>>> -
>>> +not care what value the additional bits have.  The smaller register
>>> +always overlaps the least significant bits of the larger register and
>>> +the @var{bytenum} is always zero for paradoxical registers (even on big
>>> +endian machines).  The reload pass ensures that paradoxical references
>>> +are only made to hard registers.
>>>     
>>
>> FWIW, I agree with the first sentence.  I'm not quite sure what you mean
>> by the second though.  My understanding is that reload should never
>> replace an operand with a subreg of a hard register; it should always
>> reduce it to a "reg" rtx.  I think subregs should only appear after
>> reload if they are part of an .md pattern (as in spe.md, for example).
>>
>>   
> Note that that sentence was already there.   i added the single sentence
> in the middle. 

Sorry!

Ian Lance Taylor <iant@google.com> writes:
> Richard Sandiford <rsandifo@nildram.co.uk> writes:
>>>  The other use of @code{subreg} is to extract the individual registers of
>>>  a multi-register value.  Machine modes such as @code{DImode} and
>>>  @code{TImode} can indicate values longer than a word, values which
>>>  usually require two or more consecutive registers.  To access one of the
>>>  registers, use a @code{subreg} with mode @code{SImode} and a
>>> -@var{bytenum} offset that says which register.
>>> +@var{bytenum} offset that says which register.  In this case, the
>>> +@var(bytenum) must align the outer value to a word boundary if the inner
>>        ^^^^^^^^^
>> Nit: {bytenum}
>>
>>> +register is a psuedo or to a register boundary if the inner register is
>>> +a hard register.  
>>
>> As I understand it, this is only true if the _outer_ register is
>> word-sized or bigger.  You can have (subreg:QI (reg:DI ...) 3) on
>> a 32-bit big-endian target, for example.
>
> True in general, but that is not the specific case addressed in this
> paragraph, that of extracting the individual registers of a
> multi-register value.  But perhaps this could be made more clear.

Well, it is accessing an individual register of a multi-register value.
It just isn't accessing the individual register in its full width.

The example is already talking about accessing an individual SImode-sized
register, so from that point of view, the example already implies that the
byte offset must correspond to a register boundary.  So I was afraid
that the new sentence might be read more generally as "whenever you're
accessing one register in a multi-register value, whatever its mode,
the byte offset must be aligned to a register boundary.", especially
given that this paragraph flows into one that reads:

  Storing in a non-paradoxical @code{subreg} has undefined results for
  bits belonging to the same word as the @code{subreg}.  This laxity makes
  it easier to generate efficient code for such instructions.  To
  represent an instruction that preserves all the bits outside of those in
  the @code{subreg}, use @code{strict_low_part} around the @code{subreg}.

Richard

  parent reply	other threads:[~2008-03-14 15:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-14 14:24 Kenneth Zadeck
2008-03-14 14:45 ` Richard Sandiford
2008-03-14 14:48   ` Ian Lance Taylor
2008-03-14 14:49   ` Kenneth Zadeck
2008-03-14 14:51   ` Ian Lance Taylor
2008-03-14 14:59     ` Kenneth Zadeck
2008-03-14 15:17     ` Richard Sandiford [this message]
2008-03-14 17:00       ` Kenneth Zadeck
2008-03-14 17:14         ` Richard Sandiford
2008-03-14 14:51 ` Ian Lance Taylor

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=87bq5hz6vs.fsf@firetop.home \
    --to=rsandifo@nildram.co.uk \
    --cc=bonzini@gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=zadeck@naturalbridge.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).