On Wed, Mar 23, 2016 at 10:53 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Mar 23, 2016 at 09:59:56AM +0100, Richard Biener wrote: >> Note that always when I find bugs in extract_muldiv and try >> to decipher what it does I think we need to rip that out, >> replacing it with some simple patterns and leaving the rest >> to passes like reassoc. It's simply a beast that proved to >> be a can of worms... > > That is true, but sadly any optimization removals from extract_muldiv > proved to be huge cans of worms too (e.g. in constexpr handling > or constant initializers).
Yes, I expect it is quite some work to decipher what this beast actually does and what parts of it do not have an equivalent on the GIMPLE level as well. I'm not sure if constexprs or constnat initializers need to handle arbitrary association for example. For example int a, b; constexpr int c = (((a + b) - a) - b); doesn't appear to be a valid constexpr. So for that (and the constant initializer case) I don't see the issue really unless it is coping with pointer arithmetic lowering the FEs perform and symbolic constants. And for those cases the FEs should simply avoid the lowering (and thus the ME have appropriate representation and lower itself at some point). Richard. > Jakub
