[LLVMdev] Moving towards a singular pointer type

[Chandler Carruth]

On Tue, Feb 17, 2015 at 2:44 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Feb 17, 2015 at 2:24 PM, deadal nix <deadalnix at gmail.com> wrote:
>
>> I kind of agree with that sentiment. I has various bugs in my projects
>> catched by typechecking on pointer in the past, so this change will come at
>> a real cost.
>>
>> As I understand it, the main adantage of that change is to get rid of
>> various bitcasts. Would that be possible to have a ptr_bitcast flag in
>> memory operation, indicating that the pointer type needs to be ignored ?
>>
>
> You mean leave pointer types in the IR but flag operations (like geps and
> loads) to indicate that they shouldn't care about the type of their
> operands? That'd still not get us the canonicalization benefits (store and
> gep would still produce a type that depends on its operand, etc).
>
> I think if we want the extra safety we could, after introducing the ptr
> type, add a no-op cast (like bitcast) that just documents the change in
> type so that, say, store to load could be verified. This still wouldn't
> provide the current convenience of pointee types in the LLVM IR APIs, but
> it /could/ be retrieved with some effort (oh, the load instruction says
> load an int, the ptr operand is a store instruction of... an int, etc).
>

The problem I have with all of this is that it is putting more semantic
information on the pointee type than is actually there.

At a very fundamental level, memory is *not typed* in LLVM. As such,
casting between pointer types isn't actually a bug in a large number of
real-world cases. By providing a pointee type we encourage frontend authors
to rely on this for their type management and I think that is not a sound
practice in general. It may be convenient but it doesn't bear out in
practice long term.

There are a host of other ways in which the LLVM IR is more suited to what
the optimizer wants than what a frontend might find convenient. This is but
one of them. I don't think that the advantages of convenience afforded to
frontends really justify keeping the substantial cost and complexity in the
LLVM IR and optimizer.

My 2 cents.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/f85280c8/attachment.html>