> Hi! > > When ICF encounteres a GIMPLE_PREDICT (as in the testcase) or GIMPLE_NOP, > it stops looking at further statements in the bb (assumes they must be the > same), which is of course wrong. > > I'm attaching 3 versions of the patch, the first one I've > bootstrapped/regtested on x86_64-linux and i686-linux, the second one > will handle GIMPLE_PREDICT just as (fixed) GIMPLE_NOP handling, as Honza is > saying that at this point GIMPLE_PREDICT can be ignored (but we e.g. risk > when using the same function for something different that we'll not handle > GIMPLE_PREDICT right), the third one is the most minimal one (but I'm afraid
Sorry for somewhat terse answer, I was online just briefly and could not check the code. Matching GIMPLE_PREDICT won't help you here. The predicts are consumed by pass_profile during early optimizations and converted into edge probabilities. They get removed, but only in pass_strip_predict_hints that is run as first late optimization. During IPA optimization they just sit there and are fully ignored. The reason why pass_strip_predict_hints is that we want to keep the hints during early inlining (so if function is inlined, the hints are applied to the inlined body, too). With LTO world, it proably would make moresnese to schedule predict hint removal just before we compute IPA summaries, so we do not need to stream them in/out for no reason. Richard alredy approved the change for GCC 5 that is IMO fully sufficient. We may want to keep your GIMPLE_PREDICT code if we start doing ipa-icf-gimple.c driven tail merging during early optimizations (which is a plan). Honza
