On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote:> To all, I'm moving on and accepting what appears to be the consensus of > the list, for now. >I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the basis of a decision one way or the other, its more a consequence of the decision. At the IR level, we have some great infrastructure that doesn't exist at the MI level: - The pass management tools. - A verifier that can be run before and after any pass to check the basic invariants. - The ability to serialize and deserialize to/from a human understandable (and authorable) form. I think before we invest in *significantly* more complexity and logic in the MI layer of the optimizer, we will need it to have these three things. Without them, the work will be considerably harder, and we will continue to be unable to do fine grained testing during the development of new features. We might not need all of the capabilities we have in the IR, but I think we'll need at least those used to orchestrate fine grained testing and validation. Of course, adding these to MI would be of great benefit to any number of other aspects of LLVM's development. I am *not* arguing we should eschew MI because it lacks these things. I just want people to understand that part of the cost of deciding that MI is the right layer for this is needing to invest in these pieces of the MI layer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130427/eb69a42e/attachment.html>
On Apr 27, 2013, at 8:10 AM, Chandler Carruth <chandlerc at google.com> wrote:> On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote: > To all, I'm moving on and accepting what appears to be the consensus of the list, for now. > > I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the basis of a decision one way or the other, its more a consequence of the decision. > > At the IR level, we have some great infrastructure that doesn't exist at the MI level: > > - The pass management tools. > - A verifier that can be run before and after any pass to check the basic invariants. > - The ability to serialize and deserialize to/from a human understandable (and authorable) form. > > I think before we invest in *significantly* more complexity and logic in the MI layer of the optimizer, we will need it to have these three things. Without them, the work will be considerably harder, and we will continue to be unable to do fine grained testing during the development of new features. We might not need all of the capabilities we have in the IR, but I think we'll need at least those used to orchestrate fine grained testing and validation.MI does have a verifier which can be extended if anything is lacking. I'm not seeing how improving MI passes is critical for the an instruction selector. But perhaps I am missing some important details. I agree having the ability to serialize and deserialize the IR is an important missing feature for MI. We had an intern working on this before but it wasn't successful. My vague plan is this area involves instruction selecting directly to a "generic" (and configurable) target. But it's by no means a concrete proposal. Evan> > Of course, adding these to MI would be of great benefit to any number of other aspects of LLVM's development. I am *not* arguing we should eschew MI because it lacks these things. I just want people to understand that part of the cost of deciding that MI is the right layer for this is needing to invest in these pieces of the MI layer. > _______________________________________________ > 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/20130427/10c9bac4/attachment.html>
On Sat, Apr 27, 2013 at 7:28 PM, Evan Cheng <evan.cheng at apple.com> wrote:> > On Apr 27, 2013, at 8:10 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> >> To all, I'm moving on and accepting what appears to be the consensus of >> the list, for now. > > > I want to point out something about this direction that hasn't really come > up, but I think deserves some better discussion. I don't think it should be > the basis of a decision one way or the other, its more a consequence of the > decision. > > At the IR level, we have some great infrastructure that doesn't exist at the > MI level: > > - The pass management tools. > - A verifier that can be run before and after any pass to check the basic > invariants. > - The ability to serialize and deserialize to/from a human understandable > (and authorable) form. > > I think before we invest in *significantly* more complexity and logic in the > MI layer of the optimizer, we will need it to have these three things. > Without them, the work will be considerably harder, and we will continue to > be unable to do fine grained testing during the development of new features. > We might not need all of the capabilities we have in the IR, but I think > we'll need at least those used to orchestrate fine grained testing and > validation. > > > MI does have a verifier which can be extended if anything is lacking. I'm > not seeing how improving MI passes is critical for the an instruction > selector. But perhaps I am missing some important details. >Mostly in the testability and ease of working with and modifying. MI is nice enough, but IR is extraordinarily easy to modify, serialize, and test incrementally.> I agree having the ability to serialize and deserialize the IR is an > important missing feature for MI. We had an intern working on this before > but it wasn't successful. My vague plan is this area involves instruction > selecting directly to a "generic" (and configurable) target. But it's by no > means a concrete proposal. >Nod. That's why going towards the IR legalization first, it seemed like an easy way to use an existing selector and prototype something quickly to enable legalization on an aspect of llvm that already has a great set of infrastructure - while keeping the work reasonably incremental. Also, as has been pointed out it has a lot of downsides as well. Not the least of which is the ... unpleasantness of call legalization. A generic and configurable target could work, I'm not sure how different that would be from a more lowered/legalized IR, but we should definitely chat about it after the llvm conference so we can get your ideas. Thanks for all of the comments and look forward to discussing this further with you. -eric
On Apr 27, 2013, at 11:28 AM, Evan Cheng <evan.cheng at apple.com> wrote: On Apr 27, 2013, at 8:10 AM, Chandler Carruth <chandlerc at google.com> wrote:> >> On Fri, Apr 26, 2013 at 11:33 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> To all, I'm moving on and accepting what appears to be the consensus of the list, for now. >> >> I want to point out something about this direction that hasn't really come up, but I think deserves some better discussion. I don't think it should be the basis of a decision one way or the other, its more a consequence of the decision. >> >> At the IR level, we have some great infrastructure that doesn't exist at the MI level: >> >> - The pass management tools. >> - A verifier that can be run before and after any pass to check the basic invariants. >> - The ability to serialize and deserialize to/from a human understandable (and authorable) form. >> >> I think before we invest in *significantly* more complexity and logic in the MI layer of the optimizer, we will need it to have these three things. Without them, the work will be considerably harder, and we will continue to be unable to do fine grained testing during the development of new features. We might not need all of the capabilities we have in the IR, but I think we'll need at least those used to orchestrate fine grained testing and validation. > > MI does have a verifier which can be extended if anything is lacking. I'm not seeing how improving MI passes is critical for the an instruction selector. But perhaps I am missing some important details. > > I agree having the ability to serialize and deserialize the IR is an important missing feature for MI. We had an intern working on this before but it wasn't successful. My vague plan is this area involves instruction selecting directly to a "generic" (and configurable) target. But it's by no means a concrete proposal....but MI serialization did not fail because of any fundamental problem AFAIK. There simply was an out-of-tree dependency that prevented checkin at the time. Command-line driven pass management would be nice for testing. But, the situation for MI passes is already much better than for SD sub-passes. A few important things were not made very clear in all the high-level discussion: MI can be very easily extended to represent ISD operations. MachineOperand already handles various heterogenous kinds of operands. Adding EVT/MVT would be straightforward. MI data-structures (like SD) are ammenable to incremental lowering. Target-specific transforms can easily flip opcodes and add operands. Imagine how efficient operation lowering will be in MI--just an en-masse opcode flip. Chris mentioned that we need to be able to mix register class contraints on target instructions with type constraints on ISDs. I believe this can be done in MI without inserting special bitcasts throughout. As Krysztof mentioned, we already need a way to express MI->MI patterns. We currently have pass ordering problems between target specific DAG Combine, ISEL, and machine optimizations. Performing simple lowering in one pass and deferring or replaying more complex patterns, like operand folding, would solve the problem. It would be nice to use the same infrastructure for both. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/9af3f753/attachment.html>