From: Richard Guenther <richard.guenther@gmail.com>
To: Richard Guenther <richard.guenther@gmail.com>,
Kenneth Zadeck <zadeck@naturalbridge.com>,
Mike Stump <mikestump@comcast.net>,
gcc-patches <gcc-patches@gcc.gnu.org>,
rdsandiford@googlemail.com
Subject: Re: patch to fix constant math
Date: Fri, 05 Oct 2012 12:39:00 -0000 [thread overview]
Message-ID: <CAFiYyc0Sj3+yBXRjLUG=0=_NGQiU1VqJk35hjsWqHR9bCnqspg@mail.gmail.com> (raw)
In-Reply-To: <87a9w1hzq1.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com>
On Fri, Oct 5, 2012 at 2:26 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> On Fri, Oct 5, 2012 at 1:24 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> Richard Guenther <richard.guenther@gmail.com> writes:
>>>> The issue is that unlike RTL where we "construct" double-ints from
>>>> CONST_INT/CONST_DOUBLE right now, tree has the double-int
>>>> _embedded_. That's why I say that the thing we embed in
>>>> a CONST_WIDE_INT or a tree INTEGER_CST needs to be
>>>> "bare metal", and that's what I would call wide-int.
>>>
>>> OK, but that's deliberately not what Kenny's patch calls "wide int".
>>> The whole idea is that the "bare metal" thing we embed in a
>>> CONST_WIDE_INT or tree isn't (and doesn't need to be) the same
>>> as the type that we use to operate on integers. That bare-metal
>>> thing doesn't even have to have a fixed width. (CONST_WIDE_INT
>>> doesn't have a fixed width, it's only as big as the integer
>>> needs it to be.)
>>
>> Ok, let's rephrase it this way then: the "bare metal" thing used
>> for the storage should ideally be the same in the tree IL and the RTL
>> IL _and_ the higher-level abstract wide-int.
>
> Hmm, OK, that's a straight disagreement then.
>
>>>> So to me wide-ints provide the higher-level abstraction ontop of
>>>> double-ints (which would remain the storage entity).
>>>>
>>>> Such higher-level abstraction is very useful, also for double-ints and
>>>> also on the tree level. There is no requirement to provide bigger
>>>> double-int (or wide-int) for this. Let's call this abstraction
>>>> wide-int (as opposed to my suggested more piecemail double_sint,
>>>> double_uint). You can perfectly model it ontop of the existing
>>>> double_int storage.
>>>>
>>>> As of providing larger "double-ints" - there is not much code left
>>>> (ok, quite an overstatement ;)) that relies on the implementation
>>>> detail of double-int containing exactly two HOST_WIDE_INTs.
>>>> The exact purpose of double-ints was to _hide_ this (previously
>>>> we only had routines like mul_double_with_sign which take
>>>> two HOST_WIDE_INT components). Most code dealing with
>>>> the implementation detail is code interfacing with middle-end
>>>> routines that take a HOST_WIDE_INT argument (thus the
>>>> double_int_fits_hwi_p predicates) - even wide_int has to support
>>>> this kind of interfacing.
>>>>
>>>> So, after introducing wide_int that just wraps double_int and
>>>> changing all user code (hopefully all, I guess mostly all), we'd
>>>> tackle the issue that the size of double_int's is host dependent.
>>>> A simple solution is to make it's size dependent on a target macro
>>>> (yes, macro ...), so on a 32bit HWI host targeting a 64bit 'HWI' target
>>>> you'd simply have four HWIs in the 'double-int' storage (and
>>>> arithmetic needs to be generalized to support this).
>>>
>>> I just don't see why this is a good thing. The constraints
>>> are different when storing integers and when operating on them.
>>> When operating on them, we want something that is easily constructed
>>> on the stack, so we can create temporary structures very cheaply,
>>> and can easily pass and return them. We happen to know at GCC's
>>> compile time how big the biggest integer will ever be, so it makes
>>> sense for wide_int to be that wide.
>>
>> I'm not arguing against this. I'm just saying that the internal
>> representation will depend on the host - not the number of total
>> bits, but the number of pieces.
>
> Sure, but Kenny already has a macro to specify how many bits we need
> (MAX_BITSIZE_MODE_ANY_INT). We can certainly wrap:
>
> HOST_WIDE_INT val[MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT];
>
> in a typedef if that's what you prefer.
I'd prefer it to be initially double_int, and later "fixed" to double_int
with a member like the above. Possibly renamed as well.
>>> But when storing integers we want something compact. If your
>>> machine supports 256-bit integers, but the code you're compiling
>>> makes heavy use of 128-bit integers, why would you want to waste
>>> 128 of 256 bits on every stored integer? Which is why even
>>> CONST_WIDE_INT doesn't have a fixed width.
>>>
>>> You seem to be arguing that the type used to store integers in the IR
>>> has to be same as the one that we use when performing compile-time
>>> arithmetic, but I think it's better to have an abstraction between
>>> the two.
>>
>> Well, you don't want to pay the cost dividing 256bit numbers all
>> the time when most of your numbers are only 128bit. So we don't
>> really want to perform compile-time arithmetic on the biggest
>> possible precision either.
>
> wide_int doesn't perform them in the biggest possible precision.
> It performs them in the precision of the result. It just happens
> to have enough storage to cope with all possible precisions (because
> the actual precision of the result is usually only known at GCC's runtime).
>
>>> So if you think a pair of HWIs continues to be a useful way of
>>> storing integers at the tree level, then we can easily continue
>>> to use a pair of HWIs there.
>>
>> How do you store larger ints there then?
>
> You'd need another tree code for wider integers. I'm not saying that's
> a good idea, I just wasn't sure if it's what you wanted.
Uh, ok.
>> How is CONST_WIDE_INT variable size?
>
> It's just the usual trailing variable-length array thing.
Good. Do you get rid of CONST_DOUBLE (for integers) at the same time?
>> Why can wide-int not be variable-size?
>
> Because variable-length arrays are usually more expensive
> than (still fairly small) fixed-length arrays when dealing
> with temporaries.
which is why I'd have made it a template (but I admit I didn't fully
investigate all issues). Something like
template <unsigned bits> (or bytes?)
struct wide_int {
unsigned short precision;
HOST_WIDE_INT val[(bits + HOST_BITS_PER_WIDE_INT - 1) /
HOST_BITS_PER_WIDE_INT];
};
so it would not be variable-size at compile-time but we'd be able
to constrain its maximum size. That's important for things like
CCP which keep a lattice of ints and maybe do not want to care
about tracking your new 4096-bit integers.
But maybe we don't really care.
>>> Or if you'd prefer every tree integer
>>> to be the same width as a wide_int, we can do that too. (I don't
>>> know what Kenny's tree patch does.)
>>
>> Keenys patch truncates wide-ints to two HWIs in wide-int-to-tree
>> without any checking (I claimed it's a bug, Kenny says its a feature).
>
> Only because he split the rtl and tree parts up. By "Kenny's tree patch",
> I meant the patch that he said he was going to send (part 4 as he called it).
>
> Until then, we're not regressing at the tree level, and I think
> the patch is a genuine RTL improvement on its own.
>
>>> Another advantage of abstracting away the storage type is that
>>> we could store things like an overflow flag in the wide_int
>>> (if that ever proves useful) without worrying about the impact
>>> on the tree and RTL footprint.
>>
>> Sure.
>>
>> We seem to be talking in circles. You don't seem to want (or care)
>> about a common storage for tree, RTL and wide-int. You seem to
>> care about that operate-on-wide-ints thing. I am saying if you keep
>> double-ints as-is you create two similar things which should be one thing.
>
> The idea is to get rid of double_ints altogether. They shouldn't have
> any use once everything has been converted to wide_ints.
>
>> So, make double-int storage only.
>
> The idea was to treat them as legacy and get rid of them as soon
> as we can.
>
>> What I don't see is that the patch just introduces wide-int as type
>> to do compile-time math on in RTL. It does more (the patch is large
>> and I didn't read it in detail).
>
> Yeah, it introduces things like the CONST_SCALAR_INT_P abstraction.
> But I actually find the patch easier to review like that, because both
> changes are affecting the same kinds of place.
>
>> It doesn't even try to address the same on the tree level.
>
> Because as Kenny's already said, that's a separate patch.
>
>> It doesn't address the fundamental issue of double-int size being host
>> dependent.
>
> Because the plan is to get rid of it :-)
>
> * Trivial, but it has the wrong name.
>
> * It has the wrong interface for general-precision arithmetic because
> it doesn't say how wide the value stored (or to be stored) in those
> HOST_WIDE_INTs actually is. E.g. there's no such thing as an "X-bit
> add followed by an X-bit division". You have to a "double_int-wide
> add", followed by a truncation/extension to X bits, followed by a
> "double_int-wide division", followed by another truncation/extension
> to X bits. Which we don't do in RTL; we just assume or (occasionally)
> assert that we only use double_int for modes whose precisions are
> exactly 2 * HOST_BITS_PER_WIDE_INT.
>
> * Using a fixed-length array of HOST_WIDE_INTs is too inflexible
> for size-conscious IRs, so just bumping its size probably isn't
> a good idea for them. But having a fixed-length array does
> IMO make sense for temporaries.
>
> * If we made it storage-only, it doesn't need all those operations.
>
> Which is why I agree with Kenny that double_int as it exists today
> isn't the right starting point.
Ok, I see where you are going. Let me look at the patch again.
Richard.
> Richard
next prev parent reply other threads:[~2012-10-05 12:39 UTC|newest]
Thread overview: 217+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 17:17 patch to fix Kenneth Zadeck
2012-10-03 20:47 ` Marc Glisse
2012-10-03 22:05 ` Kenneth Zadeck
2012-10-04 13:17 ` Marc Glisse
2012-10-04 15:19 ` Kenneth Zadeck
2012-10-04 16:55 ` Marc Glisse
2012-10-04 21:06 ` Marc Glisse
2012-10-04 23:02 ` Kenneth Zadeck
2012-10-05 7:05 ` Marc Glisse
2012-10-03 22:55 ` Mike Stump
2012-10-04 12:48 ` Richard Guenther
2012-10-04 13:55 ` patch to fix constant math Kenneth Zadeck
2012-10-04 16:58 ` Richard Guenther
2012-10-04 18:08 ` Kenneth Zadeck
2012-10-04 19:27 ` Richard Sandiford
2012-10-05 9:27 ` Richard Guenther
2012-10-05 9:29 ` Richard Guenther
2012-10-05 9:56 ` Richard Sandiford
2012-10-05 10:34 ` Richard Guenther
2012-10-05 11:24 ` Richard Sandiford
2012-10-05 11:42 ` Richard Guenther
2012-10-05 12:26 ` Richard Sandiford
2012-10-05 12:39 ` Richard Guenther [this message]
2012-10-05 13:11 ` Richard Sandiford
2012-10-05 13:18 ` Richard Sandiford
2012-10-05 13:53 ` Richard Guenther
2012-10-05 14:15 ` Richard Sandiford
2012-10-05 14:36 ` Richard Guenther
2012-10-05 14:41 ` Kenneth Zadeck
2012-10-05 14:53 ` Richard Sandiford
2012-10-05 13:49 ` Richard Guenther
2012-10-05 16:34 ` Kenneth Zadeck
2012-10-05 17:29 ` Richard Sandiford
2012-10-05 17:53 ` Kenneth Zadeck
2012-10-05 22:12 ` patch to fix constant math - first small patch Kenneth Zadeck
2012-10-05 22:48 ` patch to fix constant math - second " Kenneth Zadeck
2012-10-06 15:55 ` patch to fix constant math - third " Kenneth Zadeck
2012-10-08 9:08 ` Richard Guenther
2012-10-08 11:37 ` Kenneth Zadeck
2012-10-08 12:11 ` Richard Guenther
2012-10-08 19:43 ` Richard Sandiford
2012-10-09 15:10 ` patch to fix constant math - 4th patch - the wide-int class Kenneth Zadeck
2012-10-23 14:33 ` Richard Biener
2012-10-23 16:25 ` Kenneth Zadeck
2012-10-23 18:52 ` Lawrence Crowl
2012-10-23 19:27 ` Kenneth Zadeck
2012-10-23 20:51 ` Lawrence Crowl
2012-10-23 21:34 ` Kenneth Zadeck
2012-10-24 10:10 ` Richard Biener
2012-10-24 17:30 ` Mike Stump
2012-10-25 10:55 ` Richard Biener
2012-10-25 10:59 ` Kenneth Zadeck
2012-10-25 12:12 ` Richard Biener
2012-10-31 11:01 ` Richard Sandiford
2012-10-31 12:01 ` Richard Biener
2012-10-31 12:12 ` Richard Sandiford
2012-10-31 12:14 ` Richard Biener
2012-10-31 12:23 ` Richard Sandiford
2012-10-31 12:50 ` Richard Biener
2012-10-31 13:50 ` Richard Sandiford
2012-10-31 13:56 ` Richard Biener
2012-10-31 14:26 ` Kenneth Zadeck
2012-10-31 19:45 ` Mike Stump
2012-10-31 15:52 ` Kenneth Zadeck
2012-10-31 14:39 ` Kenneth Zadeck
2012-10-31 19:22 ` Mike Stump
2012-10-31 13:54 ` Kenneth Zadeck
2012-10-31 14:07 ` Richard Biener
2012-10-31 14:25 ` Kenneth Zadeck
2012-10-31 14:25 ` Richard Biener
2012-10-31 14:30 ` Kenneth Zadeck
2012-11-01 22:13 ` patch to fix constant math - 8th patch - tree-vrp.c Kenneth Zadeck
2012-11-01 22:28 ` Marc Glisse
2012-11-01 22:35 ` Kenneth Zadeck
2012-11-01 22:33 ` patch to fix constant math - 4th patch - wide-int.[ch] refresh Kenneth Zadeck
2012-11-01 22:36 ` Kenneth Zadeck
2012-11-30 16:46 ` patch to fix constant math - 4th patch - the wide-int class Kenneth Zadeck
2012-11-30 17:00 ` patch to fix constant math - 5th patch - the rtl level changes Kenneth Zadeck
2012-11-30 18:13 ` patch to add storage classes to wide int Kenneth Zadeck
2012-11-30 19:05 ` Kenneth Zadeck
2012-12-01 9:28 ` Richard Sandiford
2012-12-01 13:43 ` Kenneth Zadeck
2013-02-27 1:59 ` patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1 Kenneth Zadeck
2013-03-27 14:54 ` Richard Biener
2013-04-04 8:08 ` Kenneth Zadeck
2013-04-02 15:40 ` Richard Biener
2013-04-02 19:23 ` Kenneth Zadeck
2013-04-03 10:44 ` Richard Biener
2013-04-03 13:36 ` Kenneth Zadeck
2013-04-03 14:46 ` Richard Biener
2013-04-03 19:18 ` Kenneth Zadeck
2013-04-04 11:45 ` Richard Biener
2013-04-08 5:28 ` Comments on the suggestion to use infinite precision math for wide int Kenneth Zadeck
2013-04-08 10:32 ` Florian Weimer
2013-04-08 13:58 ` Kenneth Zadeck
2013-04-08 14:00 ` Robert Dewar
2013-04-08 14:12 ` Kenneth Zadeck
2013-04-08 14:41 ` Robert Dewar
2013-04-08 15:10 ` Kenneth Zadeck
2013-04-08 17:18 ` Robert Dewar
2013-04-08 17:22 ` Kenneth Zadeck
2013-04-08 19:14 ` Robert Dewar
2013-04-08 23:48 ` Lawrence Crowl
2013-04-09 1:22 ` Robert Dewar
2013-04-09 1:56 ` Kenneth Zadeck
2013-04-09 2:10 ` Robert Dewar
2013-04-09 7:06 ` Mike Stump
2013-04-09 8:20 ` Robert Dewar
2013-04-09 8:22 ` Kenneth Zadeck
2013-04-09 8:24 ` Robert Dewar
2013-04-09 12:42 ` Florian Weimer
2013-04-09 15:06 ` Robert Dewar
2013-04-09 16:16 ` Florian Weimer
2013-04-08 13:12 ` Richard Biener
2013-04-08 13:32 ` Kenneth Zadeck
2013-04-08 13:44 ` Robert Dewar
2013-04-08 14:26 ` Kenneth Zadeck
2013-04-08 14:35 ` Robert Dewar
2013-04-08 19:06 ` Richard Biener
2013-04-08 22:34 ` Lawrence Crowl
2013-04-09 9:47 ` Richard Biener
[not found] ` <CAGqM8fZ7NxiMnC6PTA8v6w_E6ZJ5HbjhJXzh-HAOJqaSx+7rnw@mail.gmail.com>
2013-04-10 9:44 ` Richard Biener
2013-04-10 17:43 ` Mike Stump
2013-04-10 17:53 ` Kenneth Zadeck
2013-04-08 23:46 ` Lawrence Crowl
2013-04-22 21:39 ` patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1 Richard Sandiford
2013-04-23 0:35 ` Richard Biener
2013-04-23 6:47 ` Richard Sandiford
2013-04-05 15:05 ` Kenneth Zadeck
2013-04-08 13:06 ` Richard Biener
2013-04-17 0:49 ` Kenneth Zadeck
2013-04-17 3:41 ` patch to fix constant math -5th patch, rtl Kenneth Zadeck
2013-04-24 13:25 ` Richard Biener
2013-04-24 13:37 ` Richard Sandiford
2013-04-24 14:18 ` Richard Biener
2013-04-24 14:34 ` Richard Sandiford
2013-04-24 14:37 ` Richard Biener
2013-04-24 14:53 ` Richard Sandiford
2013-04-24 15:07 ` Richard Biener
2013-04-24 15:13 ` Kenneth Zadeck
2013-04-24 15:45 ` Richard Sandiford
2013-04-24 16:51 ` Richard Biener
2013-04-24 18:24 ` Richard Sandiford
2013-05-03 11:28 ` Richard Biener
2013-05-03 12:38 ` Richard Sandiford
2013-05-03 12:53 ` Richard Biener
2013-05-03 13:50 ` Richard Sandiford
2013-05-03 14:27 ` Kenneth Zadeck
2013-04-25 8:38 ` Kenneth Zadeck
2013-05-03 11:34 ` Richard Biener
2013-05-03 11:50 ` Kenneth Zadeck
2013-05-03 12:12 ` Richard Biener
2013-05-03 12:31 ` Kenneth Zadeck
2013-05-03 12:40 ` Richard Biener
2013-05-03 14:09 ` Kenneth Zadeck
2013-05-03 12:48 ` Richard Sandiford
2013-05-03 13:06 ` Richard Biener
2013-05-03 13:23 ` Richard Sandiford
2013-05-03 15:32 ` Kenneth Zadeck
2013-04-24 14:57 ` Kenneth Zadeck
2013-04-24 15:49 ` Richard Biener
2013-04-24 17:11 ` Richard Sandiford
2013-05-03 11:19 ` Richard Biener
2013-05-03 12:46 ` Kenneth Zadeck
2013-05-03 13:02 ` Richard Biener
2013-05-03 14:34 ` Kenneth Zadeck
2013-05-02 17:22 ` Kenneth Zadeck
2013-04-17 7:34 ` patch to fix constant math - builtins.c - the first of the tree level patches for wide-int Kenneth Zadeck
2013-05-02 17:53 ` Kenneth Zadeck
2013-04-17 15:01 ` patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1 Kenneth Zadeck
2013-04-19 15:35 ` Richard Biener
2013-04-22 7:15 ` Kenneth Zadeck
2013-04-22 15:21 ` Richard Biener
2013-04-23 8:11 ` Kenneth Zadeck
2013-04-22 18:53 ` Kenneth Zadeck
2013-04-22 19:17 ` richard, i accidently pushed send rather than save, the previous email was not finished, just ignore it Kenneth Zadeck
2013-05-02 17:21 ` patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1 Kenneth Zadeck
2012-10-31 20:07 ` patch to fix constant math - 4th patch - the wide-int class Mike Stump
2012-10-23 18:10 ` Lawrence Crowl
2012-10-09 18:51 ` patch to fix constant math - patch 5 - the rest of the rtl stuff Kenneth Zadeck
2012-10-19 16:52 ` Richard Sandiford
2012-11-09 13:22 ` patch to fix constant math - third small patch Kenneth Zadeck
2012-10-08 9:07 ` patch to fix constant math - second " Richard Guenther
2012-11-08 18:14 ` Kenneth Zadeck
2012-11-26 15:31 ` Richard Biener
2013-02-27 0:28 ` patch to fix constant math - second small patch -patch ping for next stage 1 Kenneth Zadeck
2013-03-27 14:18 ` Richard Biener
2013-03-27 14:23 ` Kenneth Zadeck
2013-03-27 15:07 ` Richard Biener
2013-03-28 14:47 ` Kenneth Zadeck
2012-10-06 0:14 ` patch to fix constant math - first small patch Joseph S. Myers
2012-10-08 19:25 ` Kenneth Zadeck
2012-11-08 17:37 ` Kenneth Zadeck
2013-02-27 0:23 ` patch to fix constant math - first small patch - patch ping for the next stage 1 Kenneth Zadeck
2013-03-27 14:13 ` Richard Biener
2013-03-28 15:06 ` Kenneth Zadeck
2013-03-31 17:51 ` Kenneth Zadeck
2013-04-02 9:45 ` Richard Biener
2013-04-02 14:34 ` Kenneth Zadeck
2013-04-02 15:29 ` Richard Biener
2013-04-02 22:43 ` Kenneth Zadeck
2013-04-03 10:48 ` Richard Biener
2013-04-03 12:21 ` Kenneth Zadeck
2013-04-03 13:38 ` Richard Biener
2013-04-04 3:13 ` Kenneth Zadeck
2012-10-07 12:47 ` patch to fix constant math Richard Guenther
2012-10-07 13:11 ` Kenneth Zadeck
2012-10-07 13:19 ` Richard Guenther
2012-10-07 14:58 ` Kenneth Zadeck
2012-10-08 9:27 ` Richard Guenther
2012-10-08 15:01 ` Nathan Froyd
2012-10-08 15:11 ` Robert Dewar
2012-10-08 19:55 ` Richard Sandiford
2012-10-09 7:09 ` Richard Guenther
2012-10-08 16:18 ` Richard Guenther
2012-10-05 13:11 ` Kenneth Zadeck
2012-10-04 15:39 ` patch to fix Kenneth Zadeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFiYyc0Sj3+yBXRjLUG=0=_NGQiU1VqJk35hjsWqHR9bCnqspg@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=mikestump@comcast.net \
--cc=rdsandiford@googlemail.com \
--cc=zadeck@naturalbridge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).