On 5 May 2014 17:05, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> Obviously, this affects optimization-dependent warnings later in the >> compilation. >> >> I wonder why this happens. Shouldn't gimplification be roughly >> target-independent? > > > It turns out that it's not gimplification, but fold which is the culprit. > In fold-const.c:fold_truth_andor, we have this code: This is a known issue. See PR32643, PR60090 and specially http://gcc.gnu.org/ml/gcc/2013-11/msg00253.html And this quote from http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html >>> At present, there are still various "optimizations" done in the C front end while the trees for expressions are built up, and some cases where some folding still happens; such optimizations can be incrementally moved out of the front end into fold (or other optimizers) where they belong, and such folding during parsing incrementally disabled, moving towards trees that more closely correspond to the original source. In addition, the front end does not logically need all the transformations done by fold. In principle, fold should act on GIMPLE (so avoiding any present dependence on which subexpressions were combined into larger expressions in the source program) with the only folding done before gimplification being more limited folding required for initializers. With such a change, c_fully_fold would only need to do the more limited folding. If the C gimplification handled C_MAYBE_CONST_EXPR, some calls to c_fully_fold could be eliminated altogether; only those where the information about constancy is required, in particular for static initializers, would need to remain. However, c_fully_fold could also be thought of as a logical lowering step, converting front-end-specific structures (which presently are GENERIC plus the odd extra tree code) to GENERIC, with potentially further transformations needed in future, and increases in the amount of lowering involved (making datastructures correspond more closely to the source for longer in the front end) might require this lowering step everywhere even when folding isn't needed. <<< I'm not sure if Marek Polacek has started working on it but he probably will appreciate some help. I don't think there is even a plan or TODO list written up of what needs to be done. It would be nice to create that in the wiki and check with Joseph, Jason and the middle-end maintainers that this plan matches their expectations. My understanding at the moment is that: * Optimizations should be moved from the FEs to middle-end (or to the gimplification phase). There is the suspicion that many are already redundant or actually undone by the middle-end, but someone needs to go over each of them and verify this. * There should be a FE-specific fold limited to checking const-ness of expressions. * Another (possibly different) FE-specific fold should deal with lowering FE specific trees to pure GENERIC. * A more powerful fold should be available for more precise warnings from the FE in some specific cases (it is not clear to me if the desired behavior is to move these warnings and the folding to gimplification, or to keep this folding working on trees? Also, whether the result of this folding should be discarded or stored somewhere). * I think a result of the above is that fold in the FEs (for const-ness, warnings and lowering) should be different from fold in the middle-end (for optimization), but I am not sure if this is part of the plan. Cheers, Manuel.
