<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><div class="gmail_extra"><br><div class="gmail_quote">2015-02-17 9:31 GMT-08:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Feb 17, 2015 at 8:56 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:antoine@python.org" target="_blank">antoine@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<span><br>
Dirkjan Ochtman <dirkjan <at> <a href="http://ochtman.nl" target="_blank">ochtman.nl</a>> writes:<br>
><br>
> As far as I understand, this change is wanted because the LLVM<br>
> infrastructure derives no value from knowing the types, and there's a<br>
> cost in terms of code spent to support all of it. I've been creating a<br>
> frontend that mostly writes out plain-text IR.<br>
><br>
> Is the type-checking of pointer types still done when constructing IR<br>
> through builder APIs? Otherwise this makes debugging significantly<br>
> harder for me. I've also really liked how readable LLVM IR is, and it<br>
> would seem like this change would negatively affect the readability.<br>
<br>
</span>I kindof agree with Dirkjan. We use a similar approach (Numba calls into<br>
llvmlite to generate textual LLVM IR), and the type checking can come in<br>
handy to avoid later crashes (otherwise it's very easy to mess up a<br>
getelementptr instruction).<br>
<br>
However, llvmlite does track types on its own, so we could also add our<br>
own error checking before generating the IR.<br></blockquote></span><div><br>This change would result in decrreased readibility and a higher chance of introducing bugs.<br><br>I don't think the builder will necessarily be able to do all the required type-checking for free. Some of it won't be available even at builder-time (most obvious example would be a parameter register would have no type information to check against when performing a load - in other cases (like an alloca to a load) we could probably have some special cases to consult the type information in the source instruction & check that against the explicit type in the load - of course then we have the problem of how to whitelist the cases where you really intended to convert. In those cases we could have a builder function that tracks that information in a side table or synthetic instruction perhaps - maybe even a real no-op instruction we can emit in debug builds just to make the IR more readable/verifiable)<br><br>But I don't think that's not high on my priority list unless there's a pretty strong desire for it - just ideas of how it could be addressed.<span class="HOEnZb"><font color="#888888"><br><br>- David<br> </font></span></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
<span><font color="#888888"><br>
Antoine.<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>