https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66565
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-06-18
CC| |ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The proliferation and misunderstanding of cost units is a side effect of
> this. So we really have to move to something like:
>
> target_should_inline_call (<interesting call information from the pass>)
> target_should_ifconvert (<gimple sequences for before/after
> transformation>)
> target_combine_is_profitable_p (<before, after rtx>)
> target_should_reconstruct_value_p (<candidate RTX to either build and keep
> in registers or reconstruct in loop>)
> target_choose_preferred_addressing_mode (<list of candidate addressing
> modes for a MEM>)
So basically one hook per transformation? And each back-end will have to
factorize the common processing?
> Where we ask specific and meaningful questions of the target, rather than
> asking for a guess at costs and using that.
> The difficult argument to make will be that we have to be radical about
> this and prepared to regress many targets (in the short term)
> for the sake of ending up with a maintainable and understandable design
> for making these decisions.
We simply cannot do that, there are ~50 architectures in the compilers and this
will break them all except for a handful of them. Generally speaking, you
cannot reimplement things from scratch in a 25 years old production compiler,
you will break far more things than you will ever be able to fix or improve.
Either you implement the new scheme in addition to the old one or you fix the
old one incrementally, that's pretty much the only practical alternative.
