On 04/24/2013 05:26 PM, Chris Lattner wrote:> On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion. > > This is a great discussion to have. > >> Is LLVM IR the right level for this? > > IMO, no, definitely not. > >> The main alternative approach that's been discussed is to do FastISel to a target-independent opcode set on MachineInstrs, and then do legalization and ultimately the last phase off instruction selection proper after that. The most obvious advantage of using LLVM IR for legalization is that it's (currently) more developer-friendly. The most obvious advantage of using MachineInstrs is that they would make it easier to do low-level manipulations. Also, doing legalization on MachineInstrs would mean avoiding having LLVM-IR-level optimization passes which lower the IR, which has historically been a design goal of LLVM. > > I think that you (in the rest of your email) identify a number of specific problems with using LLVM IR for legalization. These are a lot of specific issues caused by the fact that LLVM IR is intentionally not trying to model machine issues. I'm sure you *could* try to make this work by introducing a bunch of new intrinsics into LLVM IR which would model the union of the selection dag ISD nodes along with the target specific X86ISD nodes. However, at this point, you have only modeled the operations and haven't modeled the proper type system. > > LLVM IR is just not the right level for this. You seem to think it is better than MachineInstrs because of developer friendliness, but it isn't clear to me that LLVM IR with the additions you're talking about would actually be friendly anymore :-) > > Personally, I think that the right representation for legalization is MachineInstrs supplemented with a type system that allows MVTs as well as register classes. If you are seriously interested in pushing forward on this, we should probably discuss it in person, or over beer at the next social or something. > > -Chris >I would really push towards doing this in LLVM IR as the next step. It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary. I've already thought of many things that could be very clearly and easily done in IR that are done in very convoluted ways in Selection DAG. This kind of migration could take place right now and as we thin out the selection DAG portion of things to where it is almost non existent, making a jump to just eliminate it and replacing it would be more practical. Something like soft float for example is nearly trivial to do in IR. At the risk of appearing stupid, I can say that I've really struggled to understand selection DAG and all it's facets and interaction with table gen patterns, and this after having done a whole port from scratch already by myself. Part of it is the lack of documentation but also there are too many illogical things (to me) and special cases and hacks surrounding selection DAG and tablegen. On the other hand, I recently started to write some IR level passes and it was nearly trivial for me to understand how to use it and transform it. All the classes are more or less very clean, logical and regular. I was writing transformation passes on the first day with no issues. I think that LLVM IR could be extended to allow for all the things in legalization to take place and many other parts of lowering, i.e. lowering to use some IR which has additional lower level operations. Reed
On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote:> I would really push towards doing this in LLVM IR as the next step.What makes you say that?> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary.Doing this in LLVM IR seems like a major step backwards. It gets us no closer to the ultimate goal, would add a ton of code, and would make the compiler more complex. -Chris
On 04/24/2013 07:39 PM, Chris Lattner wrote:> On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: >> I would really push towards doing this in LLVM IR as the next step. > What makes you say that? >Partly for the reasons Dan stated. For me, the IR is definitely way more friendly too and not tangled up in lots of undocumented obscurity as selection DAG is with tablegen and many other idiosyncrasies of the backend design. Solving problems with selection DAG, to me, is like playing dungeons and dragons. I feel like I need to ask the wizard for a magic spell to capture a gnome. I don't feel like I'm doing science. It's too much like a game with thousands of rules to know. I should be able to blow through many complex problems using the C++ helper classes but they are not obvious and I spend more time learning all those obscure classes and digging through code to understand them than in doing real work. With IR, my experience is exactly the opposite. Someone that understands compilers and has experience with them should not be getting tangled up in a web of complex C++ classes and undocumented tools. The C++ classes should be making things clearer and this is , for me, definitely the case with IR and not with selection DAG. I don't immediately see the need for yet another IR. It's already pretty low level. Sure you could design another lower level one that is further removed from C but I don't see that point. You yourself like people to change things with small patches. A good example of that recently was Bill Wendlings work on attributes. He added a nice forward step in a reasonable time frame. Sure, one could design from scratch a much more sophisticated way to handle attributes but how to find the time to do that and fit it in with all of what is already there is the rub. Many things in LLVM could be better if it were possible to reset the clock. We have a lot of "technical debt" already from people being in a hurry and not thinking things through nor taking the time to clean up things that were not the best choice and to document what is already there. Well, people also wanted to move forward so it's not a criticism but a statement of what is and what became for various reasons. So I think the first step is to start to shrink the work done with selection DAG as Dan has done with his work on legalization. I think that all could go very quickly and incrementally. Dan already showed that with little work, many things can be done in IR. I myself have been thinking along exactly the same lines for some time now. As a practical matter; eliminating selection DAG can be done in a simple evolutionary way by doing that same work with IR and judiciously adding new features to IR as is demanded. We would need to extend IR but it can be done in steps.>> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary. > Doing this in LLVM IR seems like a major step backwards. It gets us no closer to the ultimate goal, would add a ton of code, and would make the compiler more complex.I don't see why it's a step backwards or why it would add tons of code and make the compiler more complex. I see the exactly the opposite. Why do you think that?> -Chris >Reed
On 04/24/2013 07:39 PM, Chris Lattner wrote:> On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: >> I would really push towards doing this in LLVM IR as the next step. > > What makes you say that? > >> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary. > > Doing this in LLVM IR seems like a major step backwards. It gets us no closer to the ultimate goal, would add a ton of code, and would make the compiler more complex. > > -Chris >I did not really answer you question very succinctly because I ranted about selection DAG and that's not the issue here. So you want to have a machine ir and Dan was proposing to do it regular IR. My main reason for using regular IR is that I think it's more likely to be doable in an incremental way and I don't see how creating another IR will help things. You can add to the existing IR things that are needed to make it powerful enough to do what machine IR would do. In the end, machine IR will look just like a subset of the current IR plus some additional things so I don't see how it helps make a new one and now there will be many things that are similar to IR but with slightly different rules, a different C++ class definition, etc. I think that path to a machine IR will be very lengthy unless Apple and Google are willing to throw a lot of high quality resources that way. Reed