<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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><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.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Antoine.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div></div>