This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Simple optimization for MASK_STORE.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: Yuri Rumyantsev <ysrumyan at gmail dot com>, Jeff Law <law at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Igor Zamyatin <izamyatin at gmail dot com>
- Date: Wed, 11 Nov 2015 10:18:40 +0100
- Subject: Re: [PATCH] Simple optimization for MASK_STORE.
- Authentication-results: sourceware.org; auth=none
- References: <CAEoMCqRmV48Ytdew0azyTQWZcmfFmjX-JaLtYUz8Q3wejL2RnQ at mail dot gmail dot com> <CAFiYyc38QMSXL058QuV0TZMAku=Ur0FXhF9TEm2Lp7C_HHmWLg at mail dot gmail dot com> <CAEoMCqQy045OoQu-v0AgWv=i8FPJffSvw7dQXsAYccB-Tc8nLw at mail dot gmail dot com> <CAFiYyc0V91KWWRLmkyUBbafVnS=6ZJz0ntsF7kt8X_0W0rgS4A at mail dot gmail dot com> <CAEoMCqSc7CAn=Rp5aM47szM_B-xa+CCA6r+FhysbBvYz=pxNrQ at mail dot gmail dot com> <559F5D7B dot 6070208 at redhat dot com> <CAEoMCqT+dBfjWkGdwMiSdV_aVjKCAx9b=-OP+eoOxD8_PddkcQ at mail dot gmail dot com> <55B148AB dot 6010103 at redhat dot com> <CAFiYyc0py=1Uqx8YdN-P8-2E11w1_7hUo8YsTO2ZdGHJo21cug at mail dot gmail dot com> <55B28DCB dot 2080404 at redhat dot com> <CAFiYyc3KugH_KPLvi3ip=zX-p6dLuQQEzLyDJAVG8emELJuajg at mail dot gmail dot com> <CAEoMCqSg2s8Hy-XXuZJ_9eNySi7PTE6S1MrtaD9ZOOJmt+ht4w at mail dot gmail dot com> <CAEoMCqRLku44v9S=HbDSFa1_5Q7dx375Ck2+QfX9KjaDKkmzAA at mail dot gmail dot com> <CAFiYyc0iqN13Nxm6rBPq1GTL+hzO3wqyAKojpk2gmey-H22+2A at mail dot gmail dot com> <CAEoMCqR=nYnqLibLbdStqXM1WOu1cwn9mVc_Se26ALmYg_ze=g at mail dot gmail dot com> <CAFiYyc18GWgQKJqL=Dtq-rUSDck1prO_ho5nWftNqB_Cq90Ebg at mail dot gmail dot com> <CAEoMCqSOARTebdBQE5nJZzO1e1379tQN_w7q8cJMpNBkQOXFkw at mail dot gmail dot com> <CAFiYyc0w1WkK5ZZ7cFv2ZJ=kD0sFpdVN85XuFHYTQeWC3E1eEw at mail dot gmail dot com> <CAMbmDYY+oGih4c9XGT87EToPmO0XrchbSZPv2g-FuxnuMD12LQ at mail dot gmail dot com> <CAFiYyc0tEYsO44260xNSc0S14QPzog9H8o4uSLxKon0NCAsB9Q at mail dot gmail dot com> <CAMbmDYYdqVRLorQT1VcS0rJON-ugvU-bFdFRb5y_K_AJNJoYDA at mail dot gmail dot com>
On Tue, Nov 10, 2015 at 3:56 PM, 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> 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 <int N>
5122 inline wi::extended_tree <N>::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.
>>>>>
>>>>>