[llvm-dev] [RFC] Tablegen-erated GlobalISel Combine Rules

[Justin Bogner via llvm-dev]

Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> writes:
> On Nov 27, 2018, at 5:01 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> What I am getting at is I feel we are defining a model for a problem
>> we don't fully understand yet.
>> I understand the model is flexible enough to inject C++ code wherever
>> we want but I question why we should have to do that if we had
>> captured the problem properly in the first place. I am not saying we
>> don't capture it properly with this design, I am again saying that I
>> don't have evidence to know.
>> 
>> The reason I am so hesitant here is because it sounds like this syntax
>> is the final solution whereas I think we could explore other
>> directions (for instance extending tablegen itself for instance).
>> However, by committing to this syntax/tablegen backend, when people
>> start to adopt it, we will have to support them and more importantly
>> migrate them if we decide to change something, that's why I believe
>> this is premature.
>
> I think Daniel’s efforts here were to allow that kind of change to
> happen without disrupting users much/at all.
>
> Ultimately it comes down to whether or not the expression of combines
> accurately captures the semantics of what the combines are really
> trying to do. Having the expressions be declarative is a big step in
> that direction IMO. In the absence of concrete examples where such a
> semantic representation isn’t sufficient to do something important,
> where is the path forward? Should we have more examples of existing
> combines being represented in this way as evidence?

To add to this, I think we're in a better position to change things than
we are now once we adopt declarative expressions of combines like Daniel
is suggesting.

With the declarative model the risk is that we've come up with something
overconstrained and have to come up with something more expressive. If
this happens, it should be reasonable to script updating the rules to
whatever that more expressive form is, whether that's some different
tablegen syntax or even directly expressing things in C++ with a bit of
library support.

If we go with the alternative of continuing to write all of the rules in
C++ for now it'll be much more difficult to change in the future. The
expressiveness of C++ is unconstrained, and when the same thing can be
written six different ways it inevitably will be. If we decide to change
our model in the future updating the rules from arbitrary C++ to that
model will be a manual and labour intensive process.

Basically, I agree that we risk having to migrate people in the future,
but I think we already have that risk with the status quo and that this
proposal will make it more practical to do if we end up needing to.

> And are there any realistic alternatives for declarative
> representations combines?
>
> Amara
>> 
>> Now, again you're the one doing the work, so if you believe this step
>> brings us closer to the final design, I have no issue with that :).
>> 
>> Cheers,
>> -Quentin