[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

["zadeck at naturalbridge dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176

--- Comment #5 from Kenneth Zadeck <zadeck at naturalbridge dot com> 2012-05-02 20:35:47 UTC ---
For each mode larger than the word size of the machine, a factor is 
computed.   That factor is the number of times that mode is larger than 
a word mode.  A move is split if the cost of moving factor words in 
separate instructions is less than moving it as an aggregate.    I.e. it 
must be profitable to do the splitting into separate instructions.     
Before our patch, wide move were always split.

A similar calculation is made for zero extensions and fixed shifts, 
except that this is only done for modes that are exactly twice the size 
of a word mode.  The decision to only consider modes that are twice the 
size of word mode for the shifting is historical, we did not change that.

I disagree with the comment about "forced under the hood changes to the 
cost model...".  The cost models are there for optimizations to use to 
decide when it is desirable to perform transformations.  Our use of 
those models is consistent with the way that the models are defined.    
Individual platforms may not have properly defined all of the cases, but 
the models clearly allow the platform to define the cost of a move of 
any mode.

The original writers of this pass did not consider machines with vector 
instructions.   A vector of N word sized elements can typically be moved 
more cheaply than N scalar moves.  In the old pass, there was no way to 
suppress this splitting.    Now many platforms can move N words as fast 
as they can move 1 word.  This is the way that gcc evolves so that it is 
relevant.

Kenny

On 05/02/2012 01:58 PM, ubizjak at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
>
> --- Comment #3 from Uros Bizjak<ubizjak at gmail dot com>  2012-05-02 17:58:17 UTC ---
> (In reply to comment #1)
>
>> Lower-subreg is most likely a terrible transformation to do on later x86s but
>> is likely to have been useful on the earlier ones.  So this regression is
>> likely a good thing.
> Can you please suggest, what should be added to leave decisions as they were?
> We would like to fine tune the cost model in a controlled way, supported by the
> data from benchmarks and applications. Forced under-the-hood changes to cost
> model just don't fit this approach.
>