I was not planning to do that mangling for 4.8. My primary
justification for getting it in publicly now is that there are a large
number of places where the current compiler (both at the tree and rtl
levels) do not do optimization of the value is larger than a single
hwi. My code generalizes all of these places so that they do the
transformations independent of the size of the hwi. (in some cases at
the rtl level, the transformations were only done on 32 bit or smaller
types, but i have seen nothing like that at the tree level.) This
provides benefits for cross compilers and for ports that support timode
now.
The fact that i have chosen to do it in such a way that we will never
have this problem again is the part of the patch that richi seems to
object to.
We have patches that do the mangling for 256 for the front ends but we
figured that we would post those for comments. These are likely to be
controversial because the require extensions to the syntax to accept
large constants.
But there is no reason why the patches that fix the existing problems in
a general way should not be considered for this release.
Kenny
On 10/31/2012 10:27 AM, Jakub Jelinek wrote:
On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote:
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.
All I see on Intel is whole vector register shifts (and like on many other
ports and/or/xor/andn could be considered whole register too).
And, even if your port has 256-bit integer arithmetics, there is no mangling
for __int256_t or similar, so I don't see how you can offer such data type
as supported in the 4.8 timeframe.
Jakub
