Re: [RFC v0 0/4] Give a type to constants too

From: Christopher Li <sparse@chrisli.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Dibyendu Majumdar <mobile@majumdar.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Sparse Mailing-list <linux-sparse@vger.kernel.org>,
	Jeff Garzik <jeff@garzik.org>, Pekka Enberg <penberg@kernel.org>
Subject: Re: [RFC v0 0/4] Give a type to constants too
Date: Fri, 11 Aug 2017 08:00:50 -0400	[thread overview]
Message-ID: <CANeU7Qkzpdxc5vCdZT3Uc4Ajj1S7aL6sCR_21xBf1M1iDeSJHA@mail.gmail.com> (raw)
In-Reply-To: <20170811114937.fqzgxdqcq64jlpgn@ltop.local>

On Fri, Aug 11, 2017 at 7:49 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> The first version of the patch gave:
>         arg     %r1, $1
>         arg     %r2, a
>         call    fun, %r1, %r2
>
> The current version gives:
>         push    $1
>         push    a
>         call    fun

I think he means the push instruction is not in the bb->insns list.

I agree with that view. The push instruction is very different than
any other instruction.  It contain mostly "repeated" information.
It is only needed when two things goes together:
1) the functions is varidic,
2) the OP_SETVAL is on the varidic part of the argument.

Which is rare, most of the function call are not varidic.

Another reason is that, it actually mess up with the parsing
state. If I am writing a script to parse the linearized output.
Notice that all other instruction don't have state itself.
The PUSH has state. It need to remember the ordered
position to the parser to figure out which PUSH apply
to which calling argument.

It also take up valuable screen space when I am staring
at the linearized byte code.

That is why I am actually what to explore Linus' alternative
suggest to push. Give OP_SETVAL a size.

Linus proposal two valid solution, add size to pseudo,
or the push. I haven't explore the first one yet.

Chris