On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump <mikest...@comcast.net> wrote: > Richi has asked the we break the wide-int patch so that the individual port > and front end maintainers can review their parts without have to go through > the entire patch. This patch covers the cfg code. > > Ok?
Hmm, this is an example of a wide_int (a widest_int) being used inside a structure with long lifetime. With the patch there are two of those per loop plus up to one per statement in a loop body (quadratic in the loop depth). Currently sizeof (loop) is 160 and sizeof (nb_iter_bound) is 40 on x86_64, on the branch they are 288 and 104 - that's quite a big overhead. It looks like x86_64 defines up to XImode (eh, for whatever reason), but certainly integer math beyond __int128_t (thus TImode) is not supported. What's the reason to bound MAX_BITSIZE_MODE_ANY_INT to the excessively large value? I suppose we should have a target hook (or macro, for the ease of gen*) that defines this instead of auto-figuring it to something that's a factor of four lager than required ... Now, for the number-of-iterations stuff I really would like to keep things cheaper in some way or another. Shrinking MAX_BITSIZE_MODE_ANY_INT would be the easiest improvement for x86_64. Allocating the values separately would be another option (and then only allocate as many words as you need, of course) - there are already flags in the structure making the values valid/invalid that can then be subsumed by NULL pointers. That said, I'd like this to be addressed. Thanks, Richard.
