On 5/28/19 1:41 PM, Jakub Jelinek wrote: > On Tue, May 28, 2019 at 01:29:54PM +0200, Martin Liška wrote: >> Yes, makes sense. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ok, thanks. > >>> BTW, unrelated to this patch, what does ICF do if e.g. SSA_NAME_PTR_INFO >>> or SSA_NAME_RANGE_INFO is different between otherwise identical functions? >>> Say one having early >>> if (arg > 10) >>> __builtin_unreachable (); >>> and another one >>> if (arg > - 10) >>> __builtin_unreachable (); >>> both optimized away into SSA_NAME_RANGE_INFO of the argument before IPA (or >>> do we optimize that away only after IPA?). >>> >>> Jakub >>> >> >> Can you please provide a self-contained test-case? > > I don't have one so far, it might be only vrp1 that removes those and thus > be fine for the user written asserts. E.g. with the patch for C++ ::main argc > range it could perhaps affect code generation if we decide to ICF main with > some other function with the same content (but that patch is not in).
That's handled here: 3493 if (DECL_NAME (source->decl) 3494 && MAIN_NAME_P (DECL_NAME (source->decl))) 3495 /* If merge via wrappers, picking main as the target can be 3496 problematic. */ 3497 source = c->members[1]; > Another thing is I'm not sure how IPA-VRP vs. ICF interact, whether first > ranges would be set for the parameters and then ICF pick one function body, > or the other way around. I'll discuss that with Martin Jambor. Martin > > Jakub >
