On Nov 10, 2015, at 6:56 AM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2015-11-10 17:46 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich <enkovich....@gmail.com> >> wrote: >>> 2015-11-10 15:33 GMT+03:00 Richard Biener <richard.guent...@gmail.com>: >>>> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev <ysrum...@gmail.com> wrote: >>>>> Richard, >>>>> >>>>> I tried it but 256-bit precision integer type is not yet supported. >>>> >>>> What's the symptom? The compare cannot be expanded? Just add a pattern >>>> then. >>>> After all we have modes up to XImode. >>> >>> I suppose problem may be in: >>> >>> gcc/config/i386/i386-modes.def:#define MAX_BITSIZE_MODE_ANY_INT (128) >>> >>> which doesn't allow to create constants of bigger size. Changing it >>> to maximum vector size (512) would mean we increase wide_int structure >>> size significantly. New patterns are probably also needed. >> >> Yes, new patterns are needed but wide-int should be fine (we only need to >> create >> a literal zero AFACS). The "new pattern" would be equality/inequality >> against zero >> compares only. > > Currently 256bit integer creation fails because wide_int for max and > min values cannot be created. > It is fixed by increasing MAX_BITSIZE_MODE_ANY_INT, but it increases > WIDE_INT_MAX_ELTS > and thus increases wide_int structure. If we use 512 for > MAX_BITSIZE_MODE_ANY_INT then > wide_int structure would grow by 48 bytes (16 bytes if use 256 for > MAX_BITSIZE_MODE_ANY_INT).
Not answering for Richard, but the design of wide-int was that though the temporary space would grow, trees and rtl would not. Most wide-int values are short lived.
