Hi there, Sorry, I don't have the thread history to reply to since I normally read llvmdev through the archives, but wanted to give my .02 of feedback anyway. 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 have no qualms with not propagating any of the pointer type data to lower-level LLVM APIs and from the discussion, it seems like I'll still be allowed to have the types in there for backwards compatibility, but I wonder if it wouldn't be worthwhile to also keep some of the type-checking in the verification code, and only ditch all the type information (or, just not consider it) after that part. Cheers, Dirkjan
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. Regards Antoine.
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>