This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Biener <richard dot guenther at gmail dot com>*To*: Richard Sandiford <rdsandiford at googlemail dot com>*Cc*: Kenneth Zadeck <zadeck at naturalbridge dot com>,Mike Stump <mikestump at comcast dot net>,gcc-patches <gcc-patches at gcc dot gnu dot org>,Lawrence Crowl <crowl at google dot com>,Ian Lance Taylor <iant at google dot com>*Date*: Mon, 22 Apr 2013 22:37:24 +0200*Subject*: Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1*References*: <506C72C7 dot 7090207 at naturalbridge dot com> <87y5im3orb dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnq-hvg at mail dot gmail dot com> <87pq3y3kyk dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw at mail dot gmail dot com> <50912D85 dot 1070002 at naturalbridge dot com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A at mail dot gmail dot com> <5091331C dot 3030504 at naturalbridge dot com> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg at mail dot gmail dot com> <512D686B dot 90000 at naturalbridge dot com> <CAFiYyc3fXewAW2dU6-RHLiTQ-ZiLgdWmfwdFF6k1VqxPsrvZbQ at mail dot gmail dot com> <515B16EB dot 5020303 at naturalbridge dot com> <CAFiYyc2qWwDcqzCMpMSiQ72w5ry=a3ZpxkFkiK7OvvBA0h4eGw at mail dot gmail dot com> <515C1AFB dot 3080105 at naturalbridge dot com> <CAFiYyc12qGj92j+5yCUEpghOZXqjjAgOzS_H6QJpKvd-dyfU0A at mail dot gmail dot com> <515C55D7 dot 7020003 at naturalbridge dot com> <CAFiYyc0sp1wbq1J+FXoJWcb9UcsOWiwjJ_KaQkbbgCnddxhVzA at mail dot gmail dot com> <87y5cajqxu dot fsf at talisman dot default>

Richard Sandiford <rdsandiford@googlemail.com> wrote: >Richard Biener <richard.guenther@gmail.com> writes: >>> At the rtl level your idea does not work. rtl constants do not >have a mode >>> or type. >> >> Which is not true and does not matter. I tell you why. Quote: > >It _is_ true, as long as you read "rtl constants" as "rtl integer >constants" :-) > >> +#if TARGET_SUPPORTS_WIDE_INT >> + >> +/* Match CONST_*s that can represent compile-time constant integers. > */ >> +#define CASE_CONST_SCALAR_INT \ >> + case CONST_INT: \ >> + case CONST_WIDE_INT >> >> which means you are only replacing CONST_DOUBLE with wide-int. >> And _all_ CONST_DOUBLE have a mode. Otherwise you'd have no >> way of creating the wide-int in the first place. > >No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT. >Only floating-point CONST_DOUBLEs have a "real" mode. I stand corrected. Now that's one more argument for infinite precision constants, as the mode is then certainly provided by the operations similar to the sign. That is, the mode (or size, or precision) of 1 certainly does not matter. >>> I understand that this makes me vulnerable to the argument that we >should >>> not let the rtl level ever dictate anything about the tree level, >but the >>> truth is that a variable len rep is almost always used for big >integers. >>> In our code, most constants of large types are small numbers. >(Remember i >>> got into this because the tree constant prop thinks that left >shifting any >>> number by anything greater than 128 is always 0 and discovered that >that was >>> just the tip of the iceberg.) But mostly i support the decision to >canonize >>> numbers to the smallest number of HWIs because most of the >algorithms to do >>> the math can be short circuited. I admit that if i had to >effectively >>> unpack most numbers to do the math, that the canonization would be a >waste. >>> However, this is not really relevant to this conversation. Yes, >you could >>> get rid of the len, but this such a small part of picture. >> >> Getting rid of 'len' in the RTX storage was only a question of >whether it >> is an efficient way to go forward. And with considering to unify >> CONST_INTs and CONST_WIDE_INTs it is not. And even for >CONST_WIDE_INTs >> (which most of the time would be 2 HWI storage, as otherwise you'd >use >> a CONST_INT) it would be an improvement. > >FWIW, I don't really see any advantage in unifying CONST_INT and >CONST_WIDE_INT, for the reasons Kenny has already given. CONST_INT >can represent a large majority of the integers and it is already a >fairly efficient representation. > >It's more important that we don't pick a design that forces one >choice or the other. And I think Kenny's patch achieves that goal, >because the choice is hidden behind macros and behind the wide_int >interface. Not unifying const-int and double-int in the end would be odd. Richard. >Thanks, >Richard

**Follow-Ups**:

**References**:**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Sandiford

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |