[LLVMdev] Moving towards a singular pointer type

[deadal nix]

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 ?

2015-02-17 9:31 GMT-08:00 David Blaikie <dblaikie at gmail.com>:

>
>
> 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
>>
>
>
> _______________________________________________
> 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/6d2cafb9/attachment.html>