> likely_max_loop_iterations misses a function comment. Thanks, updatted and comitted.
> > Ugh, one more widest_int in struct loop ... (oh well). Given > that (on x86_64) sizeof(widest_int) == 40 and sizeof(tree_int_cst) == 24 > (ok, that's cheating, it's with just one HWI for the number) it looks > appealing to change the storage of these to 'tree' ... (as a followup, > using uint128_type_node or so or whatever largest integer type a > target supports). Another option is to add a GCed wide_int that we > can "allocate" - you can do this already by having a GTY HWI array > and length and using wi::from_buffer (). That way you'd avoid defining > any tree type. I am not big firend of using TREEs to represent things that are not exactly part of IL. (and even in IL I would preffer seeing fewer of them). For likely upper bound we can also cap and consider only those bounds that fits in 64bit type. Others are not useful anyway: loop will very likely not iterate more than 2^64 times ;) Honza
