From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109305 invoked by alias); 11 Nov 2015 09:18:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 108331 invoked by uid 89); 11 Nov 2015 09:18:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 11 Nov 2015 09:18:43 +0000 Received: by ykba77 with SMTP id a77so39324662ykb.2 for ; Wed, 11 Nov 2015 01:18:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.13.210.4 with SMTP id u4mr8287504ywd.68.1447233520960; Wed, 11 Nov 2015 01:18:40 -0800 (PST) Received: by 10.37.93.11 with HTTP; Wed, 11 Nov 2015 01:18:40 -0800 (PST) In-Reply-To: References: <559F5D7B.6070208@redhat.com> <55B148AB.6010103@redhat.com> <55B28DCB.2080404@redhat.com> Date: Wed, 11 Nov 2015 09:18:00 -0000 Message-ID: Subject: Re: [PATCH] Simple optimization for MASK_STORE. From: Richard Biener To: Ilya Enkovich Cc: Yuri Rumyantsev , Jeff Law , gcc-patches , Igor Zamyatin Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01320.txt.bz2 On Tue, Nov 10, 2015 at 3:56 PM, Ilya Enkovich wrote: > 2015-11-10 17:46 GMT+03:00 Richard Biener : >> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich wrote: >>> 2015-11-10 15:33 GMT+03:00 Richard Biener : >>>> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev 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. Hmm, indeed: #1 0x000000000072dab5 in wi::extended_tree<192>::extended_tree ( this=0x7fffffffd950, t=0x7ffff6a000b0) at /space/rguenther/src/svn/trunk/gcc/tree.h:5125 5125 gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) <= N); but that's not that the constants fail to be created but #5 0x00000000010d8828 in build_nonstandard_integer_type (precision=512, unsignedp=65) at /space/rguenther/src/svn/trunk/gcc/tree.c:8051 8051 if (tree_fits_uhwi_p (TYPE_MAX_VALUE (itype))) (gdb) l 8046 fixup_unsigned_type (itype); 8047 else 8048 fixup_signed_type (itype); 8049 8050 ret = itype; 8051 if (tree_fits_uhwi_p (TYPE_MAX_VALUE (itype))) 8052 ret = type_hash_canon (tree_to_uhwi (TYPE_MAX_VALUE (itype)), itype); thus the integer type hashing being "interesting". tree_fits_uhwi_p fails because it does 7289 bool 7290 tree_fits_uhwi_p (const_tree t) 7291 { 7292 return (t != NULL_TREE 7293 && TREE_CODE (t) == INTEGER_CST 7294 && wi::fits_uhwi_p (wi::to_widest (t))); 7295 } and wi::to_widest () fails with doing 5121 template 5122 inline wi::extended_tree ::extended_tree (const_tree t) 5123 : m_t (t) 5124 { 5125 gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) <= N); 5126 } fixing the hashing then runs into type_cache_hasher::equal doing tree_int_cst_equal which again uses to_widest (it should be easier and cheaper to do the compare on the actual tree representation, but well, seems to be just the first of various issues we'd run into). We eventually could fix the assert above (but then need to hope we assert when a computation overflows the narrower precision of widest_int) or use a special really_widest_int (ugh). > 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). > Is it OK for such narrow usage? widest_int is used in some long-living structures (which is the reason for MAX_BITSIZE_MODE_ANY_INT in the first place). So I don't think so. Richard. > Ilya > >> >> Richard. >> >>> Ilya >>> >>>> >>>> Richard. >>>> >>>>> Yuri. >>>>> >>>>>