This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]