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:40:25 -0400	[thread overview]
Message-ID: <CANeU7Q=q-37HBG0WjBq747SZkHaf7PbNY5h9KFeqQRzW+go-9A@mail.gmail.com> (raw)
In-Reply-To: <20170811123535.n2fulymfn6wq4zbk@ltop.local>

On Fri, Aug 11, 2017 at 8:35 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Fri, Aug 11, 2017 at 08:00:50AM -0400, Christopher Li wrote:
>>
>> I think he means the push instruction is not in the bb->insns list.
>>
>> I agree with that view.
>
> But these instructions *are* in the bb->insns list.

If they are in the bb->insns, that is even worse in my book. It means
the back end processing the IR need to remember the state to match
up push into the calling arguments. The call instruction show up *after*
the push. You are forcing the back end to simulate a push stack to
properly process  the function call. When the back end see the
push instruction, they have noway of known the following call
will use varidic or not. The back end have to save the state to
wait for the call instruction.

You might just as well give call instruction a separate type list matching
the calling one. That at least don't show up as bb->insns.

I still want to explore Linus's first suggestion, give pseudo a type.
Using the OP_SETVAL, When I get a chance.

Chris