linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dibyendu Majumdar <mobile@majumdar.org.uk>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Sparse Mailing-list <linux-sparse@vger.kernel.org>,
	Christopher Li <sparse@chrisli.org>,
	Jeff Garzik <jeff@garzik.org>, Pekka Enberg <penberg@kernel.org>
Subject: Re: [RFC v0 0/4] Give a type to constants too
Date: Thu, 16 Mar 2017 13:43:05 -0700	[thread overview]
Message-ID: <CA+55aFzWLUXdTPRRfyN+SCxDvedZ4pnCOcaYMQ17zLA-id3tJQ@mail.gmail.com> (raw)
In-Reply-To: <CACXZuxd6O_c39=So7ruVwus9OV70gVo+dkjdPGHJVwcrRjzuVg@mail.gmail.com>

On Thu, Mar 16, 2017 at 1:19 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
>
> The issue is not with the type of %r6 but %arg3 and %arg4 if these
> happen to be integer constants, and the function is variadic so we
> cannot work out the type from the function prototype.

Yes. Ok, I see the problem.

I think we could add a 'size' to the pseudo, and solve it that way.
CSE and other linearization artifacts may mean that the type is
undefined, but the size should be well-defined.

Alternatively - and this might be the better solution - the OP_CALL
instruction might be better off split up a bit. Instead of having just
that

    struct pseudo_list *arguments;

that lists the arguments, maybe it should have a

    struct instruction_list *arguments;

with a new OP_ARG instruction to generate the argument.

That way all the arguments would have a size, and always a generating
instruction.

              Linus

  reply	other threads:[~2017-03-16 20:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-11 15:47 [RFC v0 0/4] Give a type to constants too Luc Van Oostenryck
2017-03-11 15:47 ` [PATCH v0 1/4] be more careful with concat_user_list() Luc Van Oostenryck
2017-04-27 22:41   ` Christopher Li
2017-03-11 15:47 ` [PATCH v1 2/4] make space for PSEUDO_VAL have a type Luc Van Oostenryck
2017-03-11 15:47 ` [PATCH v0 3/4] add helper pseudo_type() Luc Van Oostenryck
2017-03-11 15:47 ` [PATCH v0 4/4] give a type to PSEUDO_VALs Luc Van Oostenryck
2017-03-12 20:30 ` [RFC v0 0/4] Give a type to constants, considered harmful Luc Van Oostenryck
2017-03-12 22:25   ` Dibyendu Majumdar
2017-03-16 17:20     ` Luc Van Oostenryck
2017-03-17 11:03       ` Dibyendu Majumdar
2017-03-16 17:25 ` [RFC v0 0/4] Give a type to constants too Linus Torvalds
2017-03-16 18:04   ` Dibyendu Majumdar
2017-03-16 18:14     ` Linus Torvalds
2017-03-16 18:24       ` Dibyendu Majumdar
2017-03-16 18:40         ` Linus Torvalds
2017-03-16 20:19           ` Dibyendu Majumdar
2017-03-16 20:43             ` Linus Torvalds [this message]
2017-03-16 21:19               ` Luc Van Oostenryck
2017-03-16 22:28                 ` Linus Torvalds
2017-03-16 23:12                   ` Luc Van Oostenryck
2017-03-16 23:51                     ` Linus Torvalds
2017-03-17 11:30                       ` [RFC PATCH] use OP_PUSH + OP_CALL Luc Van Oostenryck
2017-08-10 15:25               ` [RFC v0 0/4] Give a type to constants too Christopher Li
2017-08-10 22:34                 ` Luc Van Oostenryck
2017-08-11  2:14                   ` Christopher Li
2017-08-11 11:21                     ` Luc Van Oostenryck
2017-08-11 10:28                   ` Dibyendu Majumdar
2017-08-11 11:49                     ` Luc Van Oostenryck
2017-08-11 12:00                       ` Christopher Li
2017-08-11 12:35                         ` Luc Van Oostenryck
2017-08-11 12:40                           ` Christopher Li
2017-08-11 12:45                             ` Luc Van Oostenryck
2017-08-11 12:20                       ` Dibyendu Majumdar
2017-08-11 12:39                         ` Luc Van Oostenryck
2017-08-11 13:16                       ` Dibyendu Majumdar
2017-08-11 11:51                   ` Christopher Li
2017-03-16 20:42   ` Luc Van Oostenryck

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=CA+55aFzWLUXdTPRRfyN+SCxDvedZ4pnCOcaYMQ17zLA-id3tJQ@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mobile@majumdar.org.uk \
    --cc=penberg@kernel.org \
    --cc=sparse@chrisli.org \
    /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 NNTP newsgroup(s).