[macstl-dev] Re: [altivec] CSE and the single programmer

[Glen Low]

Daniel:

On 20/07/2005, at 9:29 PM, Daniel Berlin wrote:
>>
>> 1.    Can I influence or control how much of a chunk the gimplifier
>> takes of my source code?
>>
>
> Chunk? No.  It will always do the entire function body.
>
> Order? Maybe, if you stared at call graphs long enough, you could
> probably control the order it walks your function through if/then/else
> blocks with indirectly constant arguments (IE:
>
> bool foo = true;
>
> if (foo)
> {
> ...
> }
> )
>
>
> However, I wouldn't depend on such an order, there is someone who is
> considering rewriting the entire gimplifier for 4.2

Specifically, can I influence the stage just before CSE, so that CSE  
sees more of the function call?

But surely

g = f + f + f

is handled in the same chunk as

g = f + f + f + f

where of course the expression actually expands to something quite  
large and has many hidden temporaries etc.?

Yet the former compiles to one load, and the latter compiles to 4  
loads, for example.
>
>> 3.    Any general hints about how to keep the RTL or whatever
>> intermediate code size down so that the CSE module sees as much as
>> possible?
>>
>
> I wouldn't rely on RTL level CSE for much.  For 4.x+, at least on
> ppc/x86, most of what it is catching is machine specific stuff from
> lowering.
>
> You are much better off trying to get it to eliminate what you want at
> the tree level.
>
> -fdump-tree-dom-stats-details, -fdump-tree-pre-stats-details should  
> give
> you some idea what they are eliminating and not eliminating.

Is the stage before cse called ccp, is that worthwhile looking at?

>> I had to eliminate a lot of temporaries and uglify the code somewhat
>> even to get a + a + a to work... for example, in C++ it's a common
>> idiom to use a functor object that has a operator() and no data, and
>> just instantiate it anyway -- gcc 3.x+ have been good in eliminating
>> the redundant construct and destruct -- but it definitely affects the
>> CSE in 4.0+ ...
>>
>
> If you file a bug on gcc bugzilla with preprocessed source to
> 1. a version that gets eliminated
> 2. a prettier version that looks near it, but doesn't get eliminated
> (IE something easily comparable)
>
> then i'll happily take a look at it.


I'll see what I can do.




Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pixelglow.com/lists/archive/macstl-dev/attachments/20050721/a88ea162/attachment.html