Hi, On Tue, May 28 2019, 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). > 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.
IPA-ICF runs first and unifies call graph nodes. At that point the actual VRP information for IPA-VRP information are stored along call graph edges (the other bit stored along nodes are types of formal parameters), so assuming the actual call arguments have the same value ranges in the unified bodies, it should work. Martin
