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

[Kenneth Zadeck]

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