public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Hans-Peter Nilsson <hp@axis.com>
Cc: <gcc-patches@gcc.gnu.org>, jlaw@tachyum.com
Subject: Re: [PATCH] reload: Adjust comment in find_reloads about subset, not intersection
Date: Wed, 02 Feb 2022 15:16:14 +0000	[thread overview]
Message-ID: <mpta6f9fge9.fsf@arm.com> (raw)
In-Reply-To: <mptee4lfggs.fsf@arm.com> (Richard Sandiford's message of "Wed, 02 Feb 2022 15:14:43 +0000")

Richard Sandiford <richard.sandiford@arm.com> writes:
> Hans-Peter Nilsson <hp@axis.com> writes:
>>> From: Richard Sandiford <richard.sandiford@arm.com>
>>> Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>>> > The mystery isn't so much that there's code mismatching comments or
>>> > intent, but that this code has been there "forever".  There has been a
>>> > function reg_classes_intersect_p, in gcc since r0-54, even *before*
>>> > there was reload.c; r0-361, so why the "we don't have a way of forming
>>> > the intersection" in the actual patch and why wasn't this fixed
>>> > (perhaps not even noticed) when reload was state-of-the-art?
>>> 
>>> But doesn't the comment
>>
>> (the second, patched comment; removed in the patch)
>>
>>> mean that we have/had no way of getting
>>> a *class* that is the intersection of preferred_class[i] and
>>> this_alternative[i], to store as the new
>>> this_alternative[i]?
>>
>> Yes, that's likely what's going on in the (second) comment
>> and code; needing a s/intersection/a class for the
>> intersection/, but the *first* comment is pretty clear that
>> the intent is exactly to "override" this_alternative[i]: "If
>> not (a subclass), but it intersects that class, use the
>> preferred class instead".  But of course, that doesn't
>> actually have to make sense as code!  And indeed it doesn't,
>> as you say.
>>
>>> If the alternatives were register sets rather than classes,
>>> I think the intended effect would be:
>>> 
>>>   this_alternative[i] &= preferred_class[i];
>>> 
>>> (i.e. AND_HARD_REG_SET in old money).
>>> 
>>> It looks like the patch would instead make this_alternative[i] include
>>> registers that the alternative doesn't actually accept, which feels odd.
>>
>> Perhaps I put too much trust in the sanity of old comments.
>>
>> How about I actually commit this one instead?  Better get it
>> right before reload is removed.
>
> :-)  LGTM, but I'd like to hear Jeff's opinion.

So it would be a good idea if I used the right email address.

>
> Thanks,
> Richard
>
>> 8< ------- >8
>> "reload: Adjust comment in find_reloads about subset, not intersection"
>> gcc:
>>
>> 	* reload.cc (find_reloads): Align comment with code where
>> 	considering the intersection of register classes then tweaking the
>> 	regclass for the current alternative or rejecting it.
>> ---
>>  gcc/reload.cc | 15 +++++++++------
>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/gcc/reload.cc b/gcc/reload.cc
>> index 664082a533d9..3ed901e39447 100644
>> --- a/gcc/reload.cc
>> +++ b/gcc/reload.cc
>> @@ -3635,9 +3635,11 @@ find_reloads (rtx_insn *insn, int replace, int ind_levels, int live_known,
>>  		 a hard reg and this alternative accepts some
>>  		 register, see if the class that we want is a subset
>>  		 of the preferred class for this register.  If not,
>> -		 but it intersects that class, use the preferred class
>> -		 instead.  If it does not intersect the preferred
>> -		 class, show that usage of this alternative should be
>> +		 but it intersects that class, we'd like to use the
>> +		 intersection, but the best we can do is to use the
>> +		 preferred class, if it is instead a subset of the
>> +		 class we want in this alternative.  If we can't use
>> +		 it, show that usage of this alternative should be
>>  		 discouraged; it will be discouraged more still if the
>>  		 register is `preferred or nothing'.  We do this
>>  		 because it increases the chance of reusing our spill
>> @@ -3664,9 +3666,10 @@ find_reloads (rtx_insn *insn, int replace, int ind_levels, int live_known,
>>  		  if (! reg_class_subset_p (this_alternative[i],
>>  					    preferred_class[i]))
>>  		    {
>> -		      /* Since we don't have a way of forming the intersection,
>> -			 we just do something special if the preferred class
>> -			 is a subset of the class we have; that's the most
>> +		      /* Since we don't have a way of forming a register
>> +			 class for the intersection, we just do
>> +			 something special if the preferred class is a
>> +			 subset of the class we have; that's the most
>>  			 common case anyway.  */
>>  		      if (reg_class_subset_p (preferred_class[i],
>>  					      this_alternative[i]))

  reply	other threads:[~2022-02-02 15:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01  1:41 [PATCH] reload: Adjust find_reloads to comment; test intersection, not subset Hans-Peter Nilsson
2022-02-01  3:57 ` Richard Sandiford
2022-02-01 20:05   ` [PATCH] reload: Adjust comment in find_reloads about subset, not intersection Hans-Peter Nilsson
2022-02-02 15:14     ` Richard Sandiford
2022-02-02 15:16       ` Richard Sandiford [this message]
2022-02-14 19:28         ` Hans-Peter Nilsson
2022-03-19 18:43         ` Jeff Law

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=mpta6f9fge9.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hp@axis.com \
    --cc=jlaw@tachyum.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).