This is the mail archive of the
mailing list for the GCC project.
Re: patch to fix constant math - 8th patch - tree-vrp.c
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Richard Biener <richard dot guenther at gmail 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>, rdsandiford at googlemail dot com
- Date: Thu, 01 Nov 2012 18:35:39 -0400
- Subject: Re: patch to fix constant math - 8th patch - tree-vrp.c
- References: <506C72C7.firstname.lastname@example.org> <email@example.com> <50743E2B.firstname.lastname@example.org> <CAFiYyc2hQLUNzei2_cFmfDqV8GQORAMSwehrS_HEqg+r7j9Wjw@mail.gmail.com> <5936254E-4B37-4D1A-9951-C33172118127@comcast.net> <CAFiYyc1=8=LffiZ=EDBOy_uzn_ARdXk1OWxT=abYd8ot+iFp5Q@mail.gmail.com> <50891AAC.email@example.com> <CAFiYyc15kmhRWhN3tsZqJDbZ5Uh6tVa45ssiYdsytLEfqaZ4zw@mail.gmail.com> <firstname.lastname@example.org> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnqemail@example.com> <firstname.lastname@example.org> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw@mail.gmail.com> <50912D85.email@example.com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A@mail.gmail.com> <5091331C.firstname.lastname@example.org> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg@mail.gmail.com> <5092F406.email@example.com> <alpine.DEB.firstname.lastname@example.org>
either way, this needs to be investigated. it could just be my bad.
On 11/01/2012 06:28 PM, Marc Glisse wrote:
On Thu, 1 Nov 2012, Kenneth Zadeck wrote:
This patch converts tree-vpn to use wide-int. In doing so it gets
rid of all restrictions that this pass currently has on the target or
source word size.
The pass's reliance on a finite "infinite precision" representation
has been preserved. It first scans the function being compiled to
determine the largest type that needs to be represented within that
function and then it uses some multiple of that size as it's
definition of infinite.
I am currently using 4 for this value. However marc glisse claims
that this may be due to a bug and that the value should be 2. This is
something that has to be investigated further. This could easily be
my mistake or some other issue that has crept into the pass. The
value of 2 or 4 is easily changed in largest_initialize. The only
truly non mechanical transformation is in the code that multiplies
two ranges. This code uses the wide-int multiply full functions
rather than using pairs of double-ints.
(I didn't look at the patch (yet))
Er, no, I didn't claim that using 4 was wrong, I think it is good
because it makes things easier. I only claimed that the current
implementation jumps through enough hoops to make do with 2.