https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On April 15, 2016 3:31:33 PM GMT+02:00, "hubicka at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > >--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> --- >> Honza? This seems to be somewhat fragile (redirecting things to >unreachable >> but _not_ changing the actual predicates in the IL). Claiming the >> predicate is constant true is also a bit bogus (as can be seen in >following >> optimization). > >At WPA stage inliner can not update IL, so it simply redirects to >builtin_unreachable if predicate is FALSE and expects scalar passes to >be >monotonously smarter than IPA analysis. > >BB3 predicate true is conservatively correct: there is no predicate to >represent that something is not constant because we assume scalar >optimizers to >possibly be stronger than us and decide better. > >Here we manage to assume that builtin_constant_p is true and thus we >conclude >the following BB is unreachable: >BB 4 predicate:(op0[ref offset: 0] not constant) > >iftmp.0_26 = __builtin_bswap64 (_3); > > freq:0.61 size: 1 time: 1 >This is because ipa-prop analyzes the values in node_name: > >Jump functions of caller broken/2: > >callsite broken/2 -> wwn_to_u64/1 : > >param 0: UNKNOWN > >Aggregate passed by reference: > offset: 0, cst: 255 > offset: 8, cst: 255 > offset: 16, cst: 255 > offset: 24, cst: 255 > offset: 32, cst: 255 > offset: 40, cst: 255 > offset: 48, cst: 255 > offset: 56, cst: 255 > >but later we fold: > ><bb 2>: > >node_name[0] = 255; > >node_name[1] = 255; > >node_name[2] = 255; > >node_name[3] = 255; > >node_name[4] = 255; > >node_name[5] = 255; > >node_name[6] = 255; > >node_name[7] = 255; > >_14 = MEM[(const u64 *)&node_name]; > >_15 = __builtin_constant_p (_14); > > >into false (which is stupid, but conservatively correct modulo the >assumption >about IPA passes being consistently weakter than local passes). > >Making IPA passes to fold builtin_constant_p call into true is >technically >possible, if I add builtin_true and redirect to it, but it would not be >very >good if the local passes can not fold above (as the wrong arm is >taken). > >So can we possibly fix the local passes?You can't rely on this happening, >consider -fno-foo. So my original local hack was to not do this built-in constant stuff for is_refp Richard. >Honza
