[llvm-dev] Multi-Threading Compilers

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sat Mar 28 16:55:14 PDT 2020

> On Mar 28, 2020, at 1:41 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > But it doesn't - it means you write some generic code, test it with some cases & looks like it generalizes to other cases (you don't want to/can't test generic code with all possible generic arguments - that's why substitutability is important) then the code breaks when it hits a constant Value because it doesn't conform to the contract.
> It's not a break of the Liskov substitution principle, though.
> It does in the sense that all Values have a list of uses in the current API - yes, if you're proposing /changing the API/ so that Values don't have a use list API, that's one thing - but adding an assertion/runtime failure is not that. Having a runtime failure where by accessing the uses of /some/ Values is a contract violation/assertion failure/etc - that makes it not substitutable, you can't just treat all Values as equal & have to special case to avoid asking for the uses of some Values.
> Yes, if you move the use-list API down from Value, so Values don't have use lists, that's different/not what Chris is objecting to, I don't think - it was the " Making use-def chains work differently based on the dynamic type of a Value* is very problematic to me. " that was specifically the objection/liskov breaking issue.

Exactly, very well put David.  I would be much less concerned if the use list apis were sunk out of Value, but I don’t see how that could be accomplished in a realistic way.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200328/b08d3ed7/attachment-0001.html>

More information about the llvm-dev mailing list