[LLVMdev] Moving towards a singular pointer type

[David Blaikie]

On Tue, Feb 17, 2015 at 8:56 AM, Antoine Pitrou <antoine at python.org> wrote:

>
> Hi,
>
> Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes:
> >
> > As far as I understand, this change is wanted because the LLVM
> > infrastructure derives no value from knowing the types, and there's a
> > cost in terms of code spent to support all of it. I've been creating a
> > frontend that mostly writes out plain-text IR.
> >
> > Is the type-checking of pointer types still done when constructing IR
> > through builder APIs? Otherwise this makes debugging significantly
> > harder for me. I've also really liked how readable LLVM IR is, and it
> > would seem like this change would negatively affect the readability.
>
> I kindof agree with Dirkjan. We use a similar approach (Numba calls into
> llvmlite to generate textual LLVM IR), and the type checking can come in
> handy to avoid later crashes (otherwise it's very easy to mess up a
> getelementptr instruction).
>
> However, llvmlite does track types on its own, so we could also add our
> own error checking before generating the IR.
>

This change would result in decrreased readibility and a higher chance of
introducing bugs.

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)

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.

- David


>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/feb4ce00/attachment.html>