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