From: Tamar Christina <Tamar.Christina@arm.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
nd <nd@arm.com>, "jwakely@redhat.com" <jwakely@redhat.com>
Subject: RE: [PATCH]middle-end: Recursively check is_trivially_copyable_or_pair in vec.h
Date: Mon, 2 Oct 2023 13:28:19 +0000 [thread overview]
Message-ID: <VI1PR08MB53259AAB25301EB0776005F3FFC5A@VI1PR08MB5325.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <ZRrD1wTU3d1Ibe5r@tucnak>
> -----Original Message-----
> From: Jakub Jelinek <jakub@redhat.com>
> Sent: Monday, October 2, 2023 2:21 PM
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: gcc-patches@gcc.gnu.org; nd <nd@arm.com>; jwakely@redhat.com
> Subject: Re: [PATCH]middle-end: Recursively check
> is_trivially_copyable_or_pair in vec.h
>
> On Mon, Oct 02, 2023 at 01:38:53PM +0100, Tamar Christina wrote:
> > Hi All,
> >
> > I recently committed a patch that uses a nested std::pair in the second
> argument.
> > It temporarily adds a second ranking variable for sorting and then later drops
> it.
> >
> > This hits the newly added assert in vec.h. This assert made some
> > relaxation for std::pair but doesn't allow this case through. The
> > patch allows a recursive std::pair in the second argument which fixes
> bootstrap.
>
> I must say I still don't understand why using a struct ifcvt_arg_entry { tree arg;
> unsigned len, occur; }; with comments describing what the members mean
> wouldn't be a better fix, in the sorting function what exactly means
> x{1,2}.second.first and x{1,2}.second.second isn't easily understandable,
> neither from the identifiers nor from any comments.
> Seems because you use 2 separate vectors, one with just tree elements and
> another with those tree elements + 2 unsigned values cached from it for the
> sorting purpose and then rewrite the original tree vector after sorting, I don't
> really see why nested std::pair would be a better match for it than a named
> structure. Furthermore, why populate args first, then compute the extra 2
> integers in another loop pushing to argsKV and finally overwrite args with
> sorted values? Can't the first loop push tree with the 2 integers already? And
> what is the point of not using this structure later on when both args and
> argsKV vectors are live until the end of the same function?
> Can't you either pass that argsKV to others, having just one vector, or at least
> release the other vector when you don't really need it?
> Formatting style, swap? arg1 : arg0 isn't correctly formatted, missing space
> before ?.
>
> Also, ArgEntry is CamelCase which we (usually) don't use in GCC and
> additionally doesn't seem to be unique enough for ODR purposes.
> Ditto argsKV.
Ok, since these will take a lot longer to test and do I've reverted the patch
for now since bootstrap was broken.
Thanks,
Tamar
>
> > It should also still maintain the invariant that was being tested here
> > since the nested arguments should still be trivially copyable.
> >
> > Bootstrapped on aarch64-none-linux-gnu, x86_64-linux-gnu, and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > vec.h (struct is_trivially_copyable_or_pair): Check recursively in
>
> Missing "* " above.
>
> > second arg.
>
> Jakub
next prev parent reply other threads:[~2023-10-02 13:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 12:38 Tamar Christina
2023-10-02 13:21 ` Jakub Jelinek
2023-10-02 13:28 ` Tamar Christina [this message]
2023-10-03 10:27 ` Tamar Christina
2023-10-03 11:01 ` Jakub Jelinek
2023-10-03 11:41 ` Tamar Christina
2023-10-03 11:52 ` Jakub Jelinek
2023-10-05 14:01 ` Tamar Christina
2023-10-05 14:14 ` Jakub Jelinek
2023-10-06 2:23 ` Tamar Christina
2023-10-06 6:38 ` Jakub Jelinek
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=VI1PR08MB53259AAB25301EB0776005F3FFC5A@VI1PR08MB5325.eurprd08.prod.outlook.com \
--to=tamar.christina@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jwakely@redhat.com \
--cc=nd@arm.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).