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. >
