public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Martin Sebor <msebor@gmail.com>
Cc: Marek Polacek <polacek@redhat.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] unshare expressions in attribute arguments
Date: Mon, 23 Nov 2020 18:30:45 +0100	[thread overview]
Message-ID: <20201123173045.GE3788@tucnak> (raw)
In-Reply-To: <7b51c358-c3d1-0117-def9-c24f1f8e6c4c@gmail.com>

On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:
> > If the most significant bound is lost, why don't you save in the attribute
> > early only the most significant bound before it is lost
> 
> The other bounds are a part of the type so saving them in the attribute
> isn't essential.  I save all of them because it simplifies their lookup.
> With only the most significant bound in the attribute argument, looking
> up the other bounds (e.g., when checking function redeclarations for
> mismatches) will, in addition to doing what's done for the most
> significant bound, involve scanning the declarations' argument lists,
> extracting the bounds from the SAVE_EXPRs, before comparing them.
> As an example, in
> 
>   void f (int A[m][n]);
> 
> the attribute has the chain (VAR_DECL(m), VAR_DECL(n)) as arguments
> and comparing them with another declaration of f is as simple as
> traversing the chain and comparing each node value.
> 
> With the change you suggest, the attribute will only have VAR_DECL(m)
> and the least significant bound will have to be extracted from A[m]'s
> type's size which is:
> 
>   MULT (NOP (bitsizetype, NOP (sizetype, SAVE (VAR (n)))), 32)
> 
> It's possible to do but not without some additional complexity and
> cost.

I don't think it would be significant complication, on the other side you
avoid wasting compile time memory on that (GC one, which means it will be
wasted until GC collection if there is one ever).  Plus all the issues from
having the same information in multiple different places.

	Jakub


  reply	other threads:[~2020-11-23 17:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 19:00 Martin Sebor
2020-11-20 19:29 ` Marek Polacek
2020-11-20 20:28   ` Martin Sebor
2020-11-20 20:37     ` Jakub Jelinek
2020-11-20 21:30       ` Martin Sebor
2020-11-20 21:41         ` Jakub Jelinek
2020-11-20 21:54           ` Martin Sebor
2020-11-20 21:57             ` Jakub Jelinek
2020-11-20 22:44               ` Martin Sebor
2020-11-21  8:01                 ` Jakub Jelinek
2020-11-23 17:03                   ` Martin Sebor
2020-11-23 17:30                     ` Jakub Jelinek [this message]
2020-11-23 18:08                       ` Martin Sebor
2020-11-23 18:21                         ` Jakub Jelinek
2020-11-23 18:51                           ` Martin Sebor
2020-11-23 23:51                 ` Joseph Myers
2020-11-22  4:01 ` 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=20201123173045.GE3788@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    --cc=polacek@redhat.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).