On Sat, 16 Feb 2019, Jakub Jelinek wrote: > On Sat, Feb 16, 2019 at 12:10:22PM +0100, Richard Biener wrote: > > On February 16, 2019 8:12:34 AM GMT+01:00, Jakub Jelinek <ja...@redhat.com> > > wrote: > > >Both the C and C++ standard guarantee that the argc argument to main is > > >non-negative, the following patch sets (or adjusts) the corresponding > > >SSA_NAME_RANGE_INFO. While main is just one, with IPA VRP it can also > > >propagate etc. I had to change one testcase because it started > > >optimizing > > >it better (the test has been folded away), so no sinking was done. > > > > Can we handle this in _nonnegative_p? Also make it work independent of > > We could. But I was wondering if that wouldn't be too costly to check it > there for each SSA_NAME tested (at least something like is this a default > definition SSA_NAME of a PARM_DECL in MAIN_DECL_P (DECL_NAME > (current_function_decl))). Furthermore, I think VRP doesn't use the > *_nonnegative_*p APIs except for gimple_stmt_nonnegative_warnv_p > and so it would need to be repeated in VRP anyway. I vaguely remember we > didn't want to use value ranges in *nonnegative_*_p and *nonnegative_*_p > in VRP because that would cause weird behavior.
We indeed don't, but at least VR analysis in extract_range_basic uses gimple_stmt_nonnegative_warnv_p. Also the canonical place to put in "default" ranges is vr_values::get_value_range which already looks at nonnull_arg_p and existing range-info. So can you plug it there? > > langhooks by looking up the translation unit decl from cfun via walking > > contexts? > > It is very well possible that MAIN_DECL_P is true only for actual main > that _start calls even for other languages, I know for sure that > it is the case of Fortran, just haven't analyzed what exactly is Ada doing > (it has some main_identifier_node code in there), or Go, D etc. I was merely looking for sth that would work with LTO (so for later passes as well), but MAIN_NAME_P is looking for main_identifier_node and the LTO FE hard-codes this to "main" ... in fact it's "main" for all languages. > > Is this a regression? > > The patch fixes the regression on #c0 in that PR, though admittedly only > if it is in main and not in some other random function with random int > argument. So, if you want to defer this for GCC 10, I can surely wait with > that. Yeah, I think it's more appropriate for GCC 10 (and a hack for said PR). Richard. > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
