On Thu, Sep 4, 2014 at 3:06 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Sep 04, 2014 at 02:57:47PM +0200, Richard Biener wrote: >> Note that I think we arrived at the point where the loop structure >> has annotations that are required for correctness :/ (simduid >> for example - if that goes away we do ...? ICE? generate >> wrong code? I don't know - Jakub shoud). > > For safelen loops it will be just (perhaps serious) missed-optimization, > for simduid I believe it shouldn't ICE either, the IFN_GOMP* builtins would > just fold as if the vectorization factor was 1 if the loop goes away. > But it will be even significantly bigger missed-optimization.
The following is a patch abstracting away the ->header = NULL settings to a mark_loop_for_removal function and adding checking code that tries to discover suspicious cases. I see it fire on fold-const.ii compile in VRP for example: fold-const.ii.067t.vrp1:fix_loop_structure: re-discovered removed loop 6 with pointer-equal header 459 (only testcase I tried). As noted in the patch the pointer-equal header case should probably be an ICE (although it's possible we just re-allocated that basic-block ...). Richard.
loop-removal
Description: Binary data
