From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-413531-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 59162 invoked by alias); 10 Nov 2015 17:02:24 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 59110 invoked by uid 89); 10 Nov 2015 17:02:23 -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_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-HELO: resqmta-po-09v.sys.comcast.net
Received: from resqmta-po-09v.sys.comcast.net (HELO resqmta-po-09v.sys.comcast.net) (96.114.154.168) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Nov 2015 17:02:22 +0000
Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227])	by resqmta-po-09v.sys.comcast.net with comcast	id ft1v1r00M4ueUHc01t2LLu; Tue, 10 Nov 2015 17:02:20 +0000
Received: from [172.16.0.8] ([24.4.193.248])	by resomta-po-03v.sys.comcast.net with comcast	id ft2J1r00S5N1HX401t2KTV; Tue, 10 Nov 2015 17:02:19 +0000
References: <CAEoMCqRmV48Ytdew0azyTQWZcmfFmjX-JaLtYUz8Q3wejL2RnQ@mail.gmail.com> <CAFiYyc38QMSXL058QuV0TZMAku=Ur0FXhF9TEm2Lp7C_HHmWLg@mail.gmail.com> <CAEoMCqQy045OoQu-v0AgWv=i8FPJffSvw7dQXsAYccB-Tc8nLw@mail.gmail.com> <CAFiYyc0V91KWWRLmkyUBbafVnS=6ZJz0ntsF7kt8X_0W0rgS4A@mail.gmail.com> <CAEoMCqSc7CAn=Rp5aM47szM_B-xa+CCA6r+FhysbBvYz=pxNrQ@mail.gmail.com> <559F5D7B.6070208@redhat.com> <CAEoMCqT+dBfjWkGdwMiSdV_aVjKCAx9b=-OP+eoOxD8_PddkcQ@mail.gmail.com> <55B148AB.6010103@redhat.com> <CAFiYyc0py=1Uqx8YdN-P8-2E11w1_7hUo8YsTO2ZdGHJo21cug@mail.gmail.com> <55B28DCB.2080404@redhat.com> <CAFiYyc3KugH_KPLvi3ip=zX-p6dLuQQEzLyDJAVG8emELJuajg@mail.gmail.com> <CAEoMCqSg2s8Hy-XXuZJ_9eNySi7PTE6S1MrtaD9ZOOJmt+ht4w@mail.gmail.com> <CAEoMCqRLku44v9S=HbDSFa1_5Q7dx375Ck2+QfX9KjaDKkmzAA@mail.gmail.com> <CAFiYyc0iqN13Nxm6rBPq1GTL+hzO3wqyAKojpk2gmey-H22+2A@mail.gmail.com> <CAEoMCqR=nYnqLibLbdStqXM1WOu1cwn9mVc_Se26ALmYg_ze=g@mail.gmail.com> <CAFiYyc18GWgQKJqL=Dtq-rUSDck1prO_ho5nWftNqB_Cq90Ebg@mail.gmail.com> <CAEoMCqSOARTebdBQE5nJZzO1e1379tQN_w7q8cJMpNBkQOXFkw@mail.gmail.com> <CAFiYyc0w1WkK5ZZ7cFv2ZJ=kD0sFpdVN85XuFHYTQeWC3E1eEw@mail.gmail.com> <CAMbmDYY+oGih4c9XGT87EToPmO0XrchbSZPv2g-FuxnuMD12LQ@mail.gmail.com> <CAFiYyc0tEYsO44260xNSc0S14QPzog9H8o4uSLxKon0NCAsB9Q@mail.gmail.com> <CAMbmDYYdqVRLorQT1VcS0rJON-ugvU-bFdFRb5y_K_AJNJoYDA@mail.gmail.com>
In-Reply-To: <CAMbmDYYdqVRLorQT1VcS0rJON-ugvU-bFdFRb5y_K_AJNJoYDA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;	charset=us-ascii
Message-Id: <E4BB6336-DDAF-4C17-889F-D736C22635A1@comcast.net>
Cc: Richard Biener <richard.guenther@gmail.com>, Yuri Rumyantsev <ysrumyan@gmail.com>, Jeff Law <law@redhat.com>, gcc-patches <gcc-patches@gcc.gnu.org>, Igor Zamyatin <izamyatin@gmail.com>
From: Mike Stump <mikestump@comcast.net>
Subject: Re: [PATCH] Simple optimization for MASK_STORE.
Date: Tue, 10 Nov 2015 17:02:00 -0000
To: Ilya Enkovich <enkovich.gnu@gmail.com>
X-IsSubscribed: yes
X-SW-Source: 2015-11/txt/msg01247.txt.bz2

On Nov 10, 2015, at 6:56 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2015-11-10 17:46 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Tue, Nov 10, 2015 at 1:48 PM, Ilya Enkovich <enkovich.gnu@gmail.com> =
wrote:
>>> 2015-11-10 15:33 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>>>> On Fri, Nov 6, 2015 at 2:28 PM, Yuri Rumyantsev <ysrumyan@gmail.com> w=
rote:
>>>>> Richard,
>>>>>=20
>>>>> I tried it but 256-bit precision integer type is not yet supported.
>>>>=20
>>>> What's the symptom?  The compare cannot be expanded?  Just add a patte=
rn then.
>>>> After all we have modes up to XImode.
>>>=20
>>> I suppose problem may be in:
>>>=20
>>> gcc/config/i386/i386-modes.def:#define MAX_BITSIZE_MODE_ANY_INT (128)
>>>=20
>>> 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.
>>=20
>> Yes, new patterns are needed but wide-int should be fine (we only need t=
o create
>> a literal zero AFACS).  The "new pattern" would be equality/inequality
>> against zero
>> compares only.
>=20
> 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 t=
emporary space would grow, trees and rtl would not.  Most wide-int values a=
re short lived.