On Tue, Jun 14, 2016 at 10:15 PM, Jason Merrill <ja...@redhat.com> wrote: > As discussed in bug 71104, the C++ P0145 proposal specifies the evaluation > order of certain operations: > > 1. a.b > 2. a->b > 3. a->*b > 4. a(b1, b2, b3) > 5. b @= a > 6. a[b] > 7. a << b > 8. a >> b > > The second patch introduces a flag -fargs-in-order to control whether these > orders are enforced on calls. -fargs-in-order=1 enforces all but the > ordering between function arguments in #4. > > The first patch implements #5 for the built-in assignment operator by > changing the order of gimplification of MODIFY_EXPR in the back end, as > richi was also thinking about doing to fix 71104. This runs into problems > with DECL_VALUE_EXPR variables, where is_gimple_reg can be true before > gimplification and false afterward, so he checks for this situation in > rhs_predicate_for. richi, you said you were still working on 71104; is this > patch OK to put in for now, or should I wait for something better?
I wasn't too happy about the rhs_predicate_for change and I was also worried about generating a lot less optimal GIMPLE due to evaluating the predicate on un-gimplified *to_p. I wondered if we should simply gimplify *from_p with is_gimple_mem_rhs_or_call unconditionally, then gimplify *to_p and after that if (unmodified) rhs_predicate_for (*to_p) is != is_gimple_mem_rhs_or_call re-gimplify *from_p to avoid this. That should also avoid changing rhs_predicate_for. Not sure if that solves whatever you were running into with OpenMP. I simply didn't have found the time to experiment with the above or even validate my fear by say comparing .gimple dumps of cc1 files with/without the gimplification order change. Richard. > For the moment the patch turns on full ordering by default so we can see > what effect it has in routine benchmarking. This will probably back off by > the time of the GCC 7 release. > > In my own SPEC runs with an earlier version of the patch, most of the C++ > tests did not change significantly, but xalancbmk slowed down about 1%. I'm > running it again now with the current patch. > > Tested x86_64-pc-linux-gnu, applying second patch to trunk, is the first > patch OK as well? > > Jason
