On Sat, Nov 5, 2016 at 3:25 AM, Jeff Law <l...@redhat.com> wrote: > On 11/04/2016 06:26 PM, Martin Sebor wrote: >> >> While experimenting with -Walloca and cross-referencing the manual >> I noticed a few minor nits that I thought could stand to corrected >> and/or clarified. Attached is a patch. >> >> In the update I mentioned that the alloca argument must have integer >> type for the bounds checking to be recognized to make it clear that >> for example floating point arguments are not considered to be bounded >> even if they are constrained. (Apparently VRP doesn't handle those.) > > Right. VRP doesn't handle floating point. THere's been some talk of > starting to track a few key values so we can say things like "this is not a > NaN".
Yup. Basically add sth along SSA_NAME_RANGE_INFO for floats and track answers to isnan, isnormal, etc. -- basically record fpclassify () for each SSA name. I'd do this conveniently in tree-ssa-forwprop.c which iterates in RPO order, folding all stmts. The actual worker would be a int gimple_fpclassify (gimple *stmt) function classifying the result of stmt (using that SSA info on arguments). Or if you want it really fancy do it decomposed, int op_fpclassify (enum tree_code code, tree arg1 [, tree arg2 [, tree arg3]]) int op_fpclassify (enum built_in_function, tree arg1 [, tree arg2 [, tree arg3]]) Wherever we test stuff like HONOR_NANS we can replace it with sth operand specific that also evaluates the SSA info. It shouldn't be much work to start sth along this line. Richard. > > The patch is OK for the trunk. > > Thanks, > Jeff
