Quentin Colombet via llvm-dev
2018-Nov-28 22:56 UTC
[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules
Le mer. 28 nov. 2018 à 11:41, David Greene <dag at cray.com> a écrit :> > Quentin Colombet <quentin.colombet at gmail.com> writes: > > > And are there any realistic alternatives for declarative > > representations combines? > > > > Realistic I would have thought we can use the syntax we already have > > for SDISel. > > In other words, people wouldn’t have to learn yet another way of doing > > combines and when we are ready we can move everything (isel + > > combines) in one go. > > I don't think I'd want to see things go that way. Current SDISel > patterns are very limited and impose a lot of hacky workarounds for > not-too-uncommon things. If anything, I anticipate migrating isel to > what Daniel outlines rather than migrating combine to SDISel and then > migrating to yet another thing after that.Interesting, I wasn't seeing this that way (the porting combine to SDISel bit). The advantage I was seeing in reusing what we have is that ISel and combines are fundamentally the same problem and any improvement (in particular compile time) that we would have made to the existing matching state machine would have benefited everything. One thing I assumed from this proposal is that the new syntax would imply a new matching state machine and thus fragmented our effort. Again maybe that's a good thing (get rid of the past to better prepare the future), and maybe I misread the proposal and we actually reuse the same state machine and we are just discussing syntactic sugar. Point being, feel free to move as you see fit and take my comments as they are, a single person's opinion :). Cheers, Q.> > -David
Nicolai Hähnle via llvm-dev
2018-Nov-29 10:12 UTC
[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules
On 28.11.18 23:56, Quentin Colombet via llvm-dev wrote:> Le mer. 28 nov. 2018 à 11:41, David Greene <dag at cray.com> a écrit : >> >> Quentin Colombet <quentin.colombet at gmail.com> writes: >> >>> And are there any realistic alternatives for declarative >>> representations combines? >>> >>> Realistic I would have thought we can use the syntax we already have >>> for SDISel. >>> In other words, people wouldn’t have to learn yet another way of doing >>> combines and when we are ready we can move everything (isel + >>> combines) in one go. >> >> I don't think I'd want to see things go that way. Current SDISel >> patterns are very limited and impose a lot of hacky workarounds for >> not-too-uncommon things. If anything, I anticipate migrating isel to >> what Daniel outlines rather than migrating combine to SDISel and then >> migrating to yet another thing after that. > > Interesting, I wasn't seeing this that way (the porting combine to SDISel bit). > > The advantage I was seeing in reusing what we have is that ISel and > combines are fundamentally the same problem and any improvement (in > particular compile time) that we would have made to the existing > matching state machine would have benefited everything. One thing I > assumed from this proposal is that the new syntax would imply a new > matching state machine and thus fragmented our effort.Right, they are fundamentally the same thing, but as David said the current SDISel syntax is quite limiting. Multi-root patterns, instructions with multiple outputs, advanced special matches are all fairly awkward to express if they're possible at all. I think Daniel's proposal fixes all these deficiencies, and I like the new variant that uses the TableGen dag type for S-expressions a lot. It's really not that different from SDISel in the end. Cheers, Nicolai> Again maybe that's a good thing (get rid of the past to better prepare > the future), and maybe I misread the proposal and we actually reuse > the same state machine and we are just discussing syntactic sugar. > Point being, feel free to move as you see fit and take my comments as > they are, a single person's opinion :). > > Cheers, > Q. > >> >> -David > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
David Greene via llvm-dev
2018-Nov-29 15:04 UTC
[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules
Quentin Colombet <quentin.colombet at gmail.com> writes:>> I don't think I'd want to see things go that way. Current SDISel >> patterns are very limited and impose a lot of hacky workarounds for >> not-too-uncommon things. If anything, I anticipate migrating isel to >> what Daniel outlines rather than migrating combine to SDISel and then >> migrating to yet another thing after that. > > Interesting, I wasn't seeing this that way (the porting combine to SDISel bit).Ok. I though that's what you meant by, "use the syntax we already have for SDISel." What do you have in mind?> The advantage I was seeing in reusing what we have is that ISel and > combines are fundamentally the same problemYes!> and any improvement (in particular compile time) that we would have > made to the existing matching state machine would have benefited > everything.Whatever underlying algorithm is used, the TableGen syntax for the current SDISel could be improved. It's never handled multiple outputs well, subregisters cause pain and so on. I'm agnostic on the underlying algorithm.> One thing I assumed from this proposal is that the new syntax would > imply a new matching state machine and thus fragmented our effort.I think Daniel's intent is indeed to craft a new algorithm, but he should confirm that. I don't know enough about the current algorithm to form an opinion on whether a new algorithm is justified. I suspect the current algorithm reflects constraints in the current TableGen syntax, where it is hard to do certain realtively common things, but I don't know that for sure. -David
Quentin Colombet via llvm-dev
2018-Nov-29 15:31 UTC
[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules
Hi David, Le jeu. 29 nov. 2018 à 07:04, David Greene <dag at cray.com> a écrit :> Quentin Colombet <quentin.colombet at gmail.com> writes: > > >> I don't think I'd want to see things go that way. Current SDISel > >> patterns are very limited and impose a lot of hacky workarounds for > >> not-too-uncommon things. If anything, I anticipate migrating isel to > >> what Daniel outlines rather than migrating combine to SDISel and then > >> migrating to yet another thing after that. > > > > Interesting, I wasn't seeing this that way (the porting combine to > SDISel bit). > > Ok. I though that's what you meant by, "use the syntax we already have > for SDISel." What do you have in mind?That’s what I meant but for me it was not porting. I guess you’re thinking porting because of all your SDISel C++ code that you would be writing again in tablegen. I was thinking we were developing new code, not porting the C++ code, which is a mistake I realize now.> > > The advantage I was seeing in reusing what we have is that ISel and > > combines are fundamentally the same problem > > Yes! > > > and any improvement (in particular compile time) that we would have > > made to the existing matching state machine would have benefited > > everything. > > Whatever underlying algorithm is used, the TableGen syntax for the > current SDISel could be improved. It's never handled multiple outputs > well, subregisters cause pain and so on.Agree.> > I'm agnostic on the underlying algorithm.The algorithm is my concern to be honest :). The syntax as long as it is easy enough and expressive enough, I don’t really care. Though I keep thinking MIR is not the right abstraction.> > > One thing I assumed from this proposal is that the new syntax would > > imply a new matching state machine and thus fragmented our effort. > > I think Daniel's intent is indeed to craft a new algorithm, but he > should confirm that. I don't know enough about the current algorithm to > form an opinion on whether a new algorithm is justified. I suspect the > current algorithm reflects constraints in the current TableGen syntax, > where it is hard to do certain realtively common things, but I don't > know that for sure.Agree and that’s where I believe we will start to fragment our effort. Cheers, Q> > > -David >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/004bf586/attachment.html>
Daniel Sanders via llvm-dev
2018-Nov-29 20:42 UTC
[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules
> On Nov 28, 2018, at 14:56, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > Le mer. 28 nov. 2018 à 11:41, David Greene <dag at cray.com <mailto:dag at cray.com>> a écrit : >> >> Quentin Colombet <quentin.colombet at gmail.com> writes: >> >>> And are there any realistic alternatives for declarative >>> representations combines? >>> >>> Realistic I would have thought we can use the syntax we already have >>> for SDISel. >>> In other words, people wouldn’t have to learn yet another way of doing >>> combines and when we are ready we can move everything (isel + >>> combines) in one go. >> >> I don't think I'd want to see things go that way. Current SDISel >> patterns are very limited and impose a lot of hacky workarounds for >> not-too-uncommon things. If anything, I anticipate migrating isel to >> what Daniel outlines rather than migrating combine to SDISel and then >> migrating to yet another thing after that. > > Interesting, I wasn't seeing this that way (the porting combine to SDISel bit). > > The advantage I was seeing in reusing what we have is that ISel and > combines are fundamentally the same problem and any improvement (in > particular compile time) that we would have made to the existing > matching state machine would have benefited everything. One thing I > assumed from this proposal is that the new syntax would imply a new > matching state machine and thus fragmented our effort.It's definitely going to require some changes to that state machine but the intent is to have both use the same core.> Again maybe that's a good thing (get rid of the past to better prepare > the future), and maybe I misread the proposal and we actually reuse > the same state machine and we are just discussing syntactic sugar. > Point being, feel free to move as you see fit and take my comments as > they are, a single person's opinion :). > > Cheers, > Q. > >> >> -David-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/3a482715/attachment.html>