This is the mail archive of the gcc@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


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


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