linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Linux-Sparse <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, considered harmful
Date: Sun, 12 Mar 2017 22:25:48 +0000	[thread overview]
Message-ID: <CACXZuxd=G7mMX2msGh6TuQMgDYkM3G6H5O2Yab6MWbWPJmWtKA@mail.gmail.com> (raw)
In-Reply-To: <20170312203040.erc4n2iollen2274@macpro.local>

On 12 March 2017 at 20:30, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Sat, Mar 11, 2017 at 04:47:21PM +0100, Luc Van Oostenryck wrote:
>> This is a RFC for giving a type to constants/PSEUDO_VALs.
>>
>> Not having this info if fine for the linearization/simplification
>> but is quite painful once trying to generate code of it.
>>
>> This serie try to do this by:
>> - shuffling some fields in struct pseudo to allow
>>   PSEUDO_VAL to have the ::sym field too without
>>   without increasing the size of the structure.
>> - mechanically initialize each PSEUDO_VAL's ::sym
>>   with the appropriate type.
>>
>> This serie have been tested on the test suite only.
>> Thsi serie also doesn't make any use yet of this type info.
>
> I have begun to try to make use of this and I'm now convinced
> that this direction is not a viable solution for sparse.
>
> Sparse's IR is slightly lower-level that LLVM's IR, more close
> to what a real CPU would do. This can already be seen at some
> instructions (nothing like GEP in sparse), the real difference
> is less obvious but it's heer that things begin to hurt.
> Indeed, sparse's CPU-like model implies that values are typeless
> but have a size and sparse's CSE and simplification is heavily
> based on this.
> Once you try to add and maintain complete and correct typing to
> sparse's instructions so that they can be used easily by sparse-llvm
> you realize that:
> - you need to add a lot more casts
> - you need to change CSE to make things equivalent only if they
>   have the same type
> - a lot of simplifications are wrong, some can be corrected by adding
>   even more casts.
>
> So, while I'm very fine to add typing info where it was missing,
> I have no interest in making the simplifications more complex and
> of lesser quality.
>

I do not know / understand enough to comment on this but I find that
your patches are working well for sparse-llvm. In particular without
the type information in constants, I cannot see how variadic functions
can be called correctly.

If the changes done so far haven't broken anything then perhaps they
can be left in?

Regards
Dibyendu

  reply	other threads:[~2017-03-12 22:25 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 [this message]
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
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='CACXZuxd=G7mMX2msGh6TuQMgDYkM3G6H5O2Yab6MWbWPJmWtKA@mail.gmail.com' \
    --to=mobile@majumdar.org.uk \
    --cc=jeff@garzik.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --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).