[LLVMdev] [global-isel] Simplifying the simplifier

[Nuno Lopes]

Hi Jakob,

Thanks for creating this interesting proposal.
Let me just comment on this part:

>> What might be better is to put some abstract interface between 
>> instcombine and the IR, so that instcombine can be run on these 
>> pseudo-MIs as well as on IR.
>
> I like the idea of sharing code between IR and MI passes through an 
> abstract interface. I think that later stages in the IR pipeline also need 
> an instruction optimizer instead of a canonicalizer.
>
> An alternative approach would be to describe these transformations in a 
> DSL instead of C++.

>  *Legalization*
>  - What does 'more legal' mean? Can we restrict the possible legalization 
> transformations so the iterative process is guaranteed to make progress?


I've been thinking for a while that we could express the instcombine 
transformations in a DSL, and then generate the C++ code from there.  The 
advantage is that if we formalize the LLVM IR, then we can check the 
correctness of all the instcombine transformations for "free".
Moreover, instcombine has also suffered from infinite loops in the past 
(because canonicalization did not make progress for some inputs), which is 
also your concern with legalization of MI.  We have algorithms to prove 
termination of rewriting systems, so I believe we could also prove progress 
for both instcombine and MI legalization.

I'm mixing MI legalization and instcombine, since I think that the 
correctness and progress checking technology that we would need is the 
exactly the same.
I wouldn't mind working on this project.  But the time-frame on my side is 
academic, which may mean 1 or 2 years to be completed.

Nuno