This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to fix constant math - 8th patch - tree-vrp.c
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- 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, 1 Nov 2012 23:28:23 +0100 (CET)
- Subject: Re: patch to fix constant math - 8th patch - tree-vrp.c
- References: <506C72C7.7090207@naturalbridge.com> <5072BAD1.5080701@naturalbridge.com> <87txu4n41o.fsf@talisman.home> <50743E2B.6000104@naturalbridge.com> <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.8090301@naturalbridge.com> <CAFiYyc15kmhRWhN3tsZqJDbZ5Uh6tVa45ssiYdsytLEfqaZ4zw@mail.gmail.com> <87y5im3orb.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnq-hvg@mail.gmail.com> <87pq3y3kyk.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw@mail.gmail.com> <50912D85.1070002@naturalbridge.com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A@mail.gmail.com> <5091331C.3030504@naturalbridge.com> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg@mail.gmail.com> <5092F406.9060101@naturalbridge.com>
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.
--
Marc Glisse