This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Record likely upper bounds for loops
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 27 May 2016 14:15:15 +0200
- Subject: Re: Record likely upper bounds for loops
- Authentication-results: sourceware.org; auth=none
- References: <20160527111409 dot GA44464 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1605271347520 dot 13344 at t29 dot fhfr dot qr>
> 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