<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 2:44 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 17, 2015 at 2:24 PM, deadal nix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br><br></div>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 ?<br></div></blockquote></span><div><br>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).<br><br>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).</div></blockquote></div><br>The problem I have with all of this is that it is putting more semantic information on the pointee type than is actually there.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My 2 cents.</div><div class="gmail_extra">-Chandler</div></div>