<div><div dir="auto">Hi David,</div></div><div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 29 nov. 2018 à 07:04, David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quentin Colombet <<a href="mailto:quentin.colombet@gmail.com" target="_blank">quentin.colombet@gmail.com</a>> writes:<br>
<br>
>> I don't think I'd want to see things go that way.  Current SDISel<br>
>> patterns are very limited and impose a lot of hacky workarounds for<br>
>> not-too-uncommon things.  If anything, I anticipate migrating isel to<br>
>> what Daniel outlines rather than migrating combine to SDISel and then<br>
>> migrating to yet another thing after that.<br>
><br>
> Interesting, I wasn't seeing this that way (the porting combine to SDISel bit).<br>
<br>
Ok.  I though that's what you meant by, "use the syntax we already have<br>
for SDISel."  What do you have in mind?</blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> The advantage I was seeing in reusing what we have is that ISel and<br>
> combines are fundamentally the same problem <br>
<br>
Yes!<br>
<br>
> and any improvement (in particular compile time) that we would have<br>
> made to the existing matching state machine would have benefited<br>
> everything.<br>
<br>
Whatever underlying algorithm is used, the TableGen syntax for the<br>
current SDISel could be improved.  It's never handled multiple outputs<br>
well, subregisters cause pain and so on.</blockquote><div dir="auto"><br></div><div dir="auto">Agree.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
I'm agnostic on the underlying algorithm.</blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> One thing I assumed from this proposal is that the new syntax would<br>
> imply a new matching state machine and thus fragmented our effort.<br>
<br>
I think Daniel's intent is indeed to craft a new algorithm, but he<br>
should confirm that.  I don't know enough about the current algorithm to<br>
form an opinion on whether a new algorithm is justified.  I suspect the<br>
current algorithm reflects constraints in the current TableGen syntax,<br>
where it is hard to do certain realtively common things, but I don't<br>
know that for sure.</blockquote><div dir="auto"><br></div><div dir="auto">Agree and that’s where I believe we will start to fragment our effort.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Q</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
                               -David<br>
</blockquote></div></div>