On Sun, Aug 05, 2018 at 09:37:32PM +0100, Ramsay Jones wrote: > > > On 04/08/18 21:35, Luc Van Oostenryck wrote: > > linearize_logical() call linearize_conditional() but needs additional > > tests there and generate code more complicated than needed. > > > > Change this by expanding the call to linearize_conditional() and make > > the obvious simplification concerning the shortcut expressions 0 & 1. > > Also, removes the logical-specific parts in linearize_conditional(), > > since there are now unneeded. > > > > Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> > > Hmm, am I understanding this correctly; you have in essence reverted > the previous patch and implemented something better? Almost but not exactly. > Why bother with the previous patch? Mainly for reasons of testing and separation of intents. The previous patch fixed a problem related to the type consistency of phi-nodes operands. The change directly addressed the problem with a rather straightforward/kinda minimal fix. The test results show that the problem is fixed. Things could stop there. The current patch is an optimization. It optimizes away one of the test introduced in the previous patch but it also optimizes away parts unrelated to the previous patch. It can also be considered as a preparatory step for the following patch. If I would have merged both patches in one, I would have hard to describe it's purpose: "fix this *AND* move the code around to simplify that". I prefer to keep them separated. The fact that this patch undoes parts of what was introduced in the previous patch is not very important. One thing I considered was to invert the order of the patches: first the two with the optimization then the one with the fix. The patches would have been a bit easier to understand but it would needed some additional work for the same result (the fix was written several days before the optimization, was already well validated, ...). I also like to do fixes first and optimizations later: if there is some complication, the optimizations can always be dropped or easily reverted. -- 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
