GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

[Kenneth Zadeck]

jakub

my port has 256 bit integers.   They are done by strapping together all 
of the elements of a vector unit.
if one looks at where intel is going, they are doing exactly the same 
thing.    The difference is that they like to add the operations one at 
a time rather than just do a clean implementation like we did.   Soon 
they will get there, it is just a matter of time.

i understand the tree-vrp code well enough to say that this operation 
does not work if you have timode, but i do not know how to translate 
that back into c to generate a test case.    My patch to tree-vrp is 
adaptable in that it looks at the types in the program and adjusts its 
definition of infinite precision based on the code that it sees.  I can 
point people to that code in tree vrp and am happy to do that, but that 
is not my priority now.

also, richi pointed out that there are places in the tree level constant 
propagators that require infinite precision so he is really the person 
who both should know about this and generate proper tests.

kenny

On 10/31/2012 09:55 AM, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote:
>> The tree-vpn uses an infinite-precision view of arithmetic. However,
>> that infinite precision is implemented on top of a finite, CARVED IN
>> STONE, base that is and will always be without a patch like this,
>> 128 bits on an x86-64.    However, as was pointed out by earlier,
>> tree-vrp needs 2 * the size of a type + 1 bit to work correctly.
>> Until yesterday i did not fully understand the significance of that
>> 1 bit.  what this means is that tree-vrp does not work on an x86-64
>> with _int128 variables.
> If you see a VRP bug, please file a PR with a testcase, or point to existing
> PR.  I agree with richi that it would be better to add a clean wide_int
> implementation for 4.9, rather than rushing something in, introducing
> lots of bugs, just for a port that hasn't been submitted, nor I understand
> why > int128_t integer types are so crucial to your port, the vector
> support doesn't generally need very large integers, even if your
> vector unit is 256-bit, 512-bit or larger.
>
> 	Jakub