This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
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.
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.