[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 #7 from Kenneth Zadeck <zadeck at naturalbridge dot com> 2012-05-02 21:19:18 UTC ---
I do apologize for the lack of heads up.    that was a mistake on our part.

I am also a little skeptical about the simple rtl cost model being good 
enough to encompass every machine in every case.    But it is better to 
tie the optimization to a cost model than have it just assume that every 
machine does or does not do something.   There are several machines for 
which this pass only does harm and gcc ought to work well for us also.

But there is a legitimate question as to how you want to control what a 
pass does.   I have a multiple issue machine with asymmetric execution 
units and the rtl cost model is not really good enough to model that.   
However the rtl cost model does appear to be good enough for this pass.

I contacted iant before I started this, and he said that the proper plan 
is to use the rtl cost model. So that is what we did.  The alternative 
is to define a bunch of special target hooks and no one seemed to want 
to go there.

Kenny

On 05/02/2012 05:05 PM, hp at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
>
> Hans-Peter Nilsson<hp at gcc dot gnu.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |hp at gcc dot gnu.org
>
> --- Comment #6 from Hans-Peter Nilsson<hp at gcc dot gnu.org>  2012-05-02 21:05:08 UTC ---
> cris-elf too.  The "set the rtl costs correctly" comment assumes there's a
> single linear cost metric shared by all gcc, not leading to pessimization
> somewhere else.
> We'll see about that.  IMHO, since you expected this to happen, a message with
> a heads-up to target maintainers would have been nicer than just trapping a
> test-case to silently fail; I had to search the (as always backlogged) mailing
> lists to find the discussion (no URL, local mailbox).
>