H Luc, On 9 September 2017 at 03:06, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Fri, Sep 08, 2017 at 11:28:57AM +0100, Dibyendu Majumdar wrote: >> >> 1. Firstly I think it is important to retain the existing "pre-phi" >> linear code. This is fine for backends such as LLVM which do a good >> job of transforming code anyway. It is also usually less buggy and >> serves as a baseline for correctness. So after careful consideration I >> would vote against adding phi instructions in the initial phase. > > That's forgetting that even with the "old/current" method create > phi-nodes during linearization: > - for the return mechanism > - for some conditionals > > This also doesn't really take in account the fact that the SSA form > is pretty fundamental to sparse (like it's most modern compilers). > I do not agree that the phi nodes "must" be present in the initial linear output. In fact if you look at clang output, initial linear output has allocas, and loads/stores. Later on these get converted to phi nodes. As long as the SSA property is maintained, which it is for Sparse, then this is fine in my view. I have some practical reasons for it: a) In the JIT world, we often want fast compilation. I already disable all subsequent phases, and generate code from the initial linear output. b) Introducing phi nodes and then taking them out doesn't help because it creates extra steps. I haven't yet tried the unssa option yet - I may have a look at this at some point. c) As both LLVM backend and my new backend use load/stores and allocas anyway, the presence of phi nodes just makes the output more convoluted as I showed earlier. d) You are right that some phi nodes are output already in the initial linear output. I would have preferred if this wasn't the case of course. Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
