linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>,
	Nicolai Stange <nicstange@gmail.com>
Subject: Re: [PATCH v4 00/25] improve constexpr handling
Date: Fri, 11 Aug 2017 00:00:54 +0200	[thread overview]
Message-ID: <CAExDi1TFOoKTua0N6_w3EA14THS3fvON8URY_AeFc1vsPY17kg@mail.gmail.com> (raw)
In-Reply-To: <CANeU7QkXi8+yi3RcY6a=WtKo9LgEgKi_CjpW-bEvHFhuu=FgVA@mail.gmail.com>

On Thu, Aug 10, 2017 at 2:36 PM, Christopher Li <sparse@chrisli.org> wrote:

> I would like the manipulate of the bits representation abstract as
> higher level function or macros. I have suspicious that bits
> representation can be simplify in the future. Wrap them into
> higher level function at the call site will be easier to read what
> is the intend for this operation.
>
> It also make the change of the underlying bit representation easier,
> that is if we do found a simpler representation.

It's many months ago so I may not remember the details correctly but ...

The initial version Nicolai posted (or maybe it was the second) *had*
function to abstract the operations and it was, IMO, really not very readable
and I asked him to change to something simpler like simply using
X |= M or X &= ~M when possible.
It's what he did and it was, IMO, much more readable.

Meanwhile, I also tried on my side to have some nice & cleaner bit
representation. It looked promising at first but was deceiving at the end.

So, I think that this series is much more valuable upstreamed than waiting
for some hypothetical super clean abstract layer for those few bits.
Of course, if you have some concrete set of patches making this better,
I would be glad to take a look at it and change my mind.
Otherwise, please consider it for upstreaming directly after the release
and improving the bit representation and the abstraction layer can always
be done later too.

-- Luc

  reply	other threads:[~2017-08-10 22:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31  1:44 [PATCH v4 00/25] improve constexpr handling Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 01/25] constexpr: introduce additional expression constness tracking flags Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 02/25] constexpr: init flags at expression allocation Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 03/25] constexpr: examine constness of casts at evaluation only Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 04/25] constexpr: examine constness of binops and alike " Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 05/25] constexpr: examine constness of preops " Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 06/25] constexpr: examine constness of conditionals " Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 07/25] constexpr: add support for tagging arithmetic constant expressions Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 08/25] constexpr: add support for tagging address constants Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 09/25] constexpr: rename handle_simple_initializer() to handle_initializer() Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 10/25] constexpr: collect storage modifiers of initializers Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 11/25] constexpr: check static storage duration objects' intializers' constness Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 12/25] constexpr: recognize static objects as address constants Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 13/25] constexpr: recognize address constants created through casts Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 14/25] constexpr: recognize address constants created through pointer arithmetic Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 15/25] constexpr: recognize members of static compound objects as address constants Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 16/25] constexpr: recognize string literals " Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 17/25] constexpr: recognize references to labels " Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 18/25] constexpr: examine constness of __builtin_offsetof at evaluation only Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 19/25] constexpr: flag builtins constant_p, safe_p and warning as constexprs Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 20/25] constexpr: relax some constant expression rules for pointer expressions Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 21/25] constexpr: support compound literals as address constants Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 22/25] constexpr: treat comparisons between types as integer constexpr Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 23/25] return an error if too few args Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 24/25] give default return type in evaluate_call() Luc Van Oostenryck
2017-03-31  1:44 ` [PATCH v4 25/25] constexpr: flag __builtin_bswap() as constexpr Luc Van Oostenryck
2017-08-10 12:36 ` [PATCH v4 00/25] improve constexpr handling Christopher Li
2017-08-10 22:00   ` Luc Van Oostenryck [this message]
2017-08-11  1:24     ` Christopher Li
2017-08-11 11:14       ` 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=CAExDi1TFOoKTua0N6_w3EA14THS3fvON8URY_AeFc1vsPY17kg@mail.gmail.com \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=nicstange@gmail.com \
    --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).