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

From: Dibyendu Majumdar <mobile@majumdar.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
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 18:24:05 +0000	[thread overview]
Message-ID: <CACXZuxdfb8p2qtMZ9ggBFZ1oz-WM-MZFX22oPXkp58FK6Ura1A@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFyVDASFQA=DsOKcTvLxA9NmsyZZpBOFovuTm8WJwb36vQ@mail.gmail.com>

Hi Linus,

On 16 March 2017 at 18:14, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Mar 16, 2017 at 11:04 AM, Dibyendu Majumdar
> <mobile@majumdar.org.uk> wrote:
>>
>> I think that having the size and information whether an integer
>> constant is an integer or pointer should be good enough
>
> The thing is, I don't think you should should actually look at the
> pseudo for that AT ALL.
>
> The size is encoded in the operation itself, and that's what you should use.
>

Agreed and we are doing that except that the function call instruction
only has the type of the call, not the arguments (as far as I
understand - apologies if I have got this wrong). The original issue
arose out of that - i.e. the code was using the type of the call
instruction to decide the type of the argument. To solve this we are
now using the function prototype to work out the types of arguments -
this works okay except for the variadic case.

> Now, the "integer vs pointer" thing is perhaps more interesting. We do
> *not* encode that, and we use the same "add" operation for both
> integers and pointer values. That's because basically linearization
> treats pointers as integers too, although we do actually keep the
> pseudos separate because we consider casts to/from pointers to be
> special (so they aren't _purely_ just integers).
>
> So the instruction itself has
>
>  - size
>
>  - sign
>
>  - _much_ of optype
>
> and I think that the proper long-term fix is perhaps to try to make
> that "much" into "all". And part of that may actually be about getting
> rid of some of the type differences entirely (ie turn pointers truly
> into just pointer-sized integers, the way they almost are already).
>
> That does mean that the llvm interface would need to use even more
> explicit casts to make llvm happy.
>

I think that is fine. I have ended up always casting values to their
expected types in sparse-llvm on the basis that a) the linearized
output has already worked out that it is legal, and b) the casts are
just to keep LLVM happy.

Thanks and Regards
Dibyendu