On Tue, Sep 12, 2017 at 12:06 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > 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. I fail to see where someone said they must. It's a fact though, that currently, during linearization, sparse already create phi-nodes for return values and for some conditional expressions. > 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. Amusingly, the Simple SSA method was (partially) created for such uses. I think you can easily understand why. Anyway, I'm more than a bit tired of this 'debate', mainly based by half-truths, assumptions and misunderstandings. As I have already stated twice, I've put the code for SSSA on hold, focusing instead on the *correct* conversion of the *others variables* (since SSSA is only concerned by local variables which can never be aliased to anything, depending on your code that can be most variables or only a small number). When I'll have something I'm happy with, I'll evaluate (read: "based on numbers") if there is any value left to the SSSA method or not. If I see there is a significant value for some uses, I'll submit it and we can have this 'debate'. *If* the code reaches upstream and bothers you too much, as you had already asked for, you will be able to disable it by simply doing so that the call to 'is_promotable()' always returns false and you will have all your nice stores & loads. Meanwhile, the current code is broken and the existing code with SSSA *can* be used to test, experiment, evaluate, compare, ... -- Luc -- 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
