This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: combiner: how to compute cost for bit insertion?


On 10.07.2017 23:40, Segher Boessenkool wrote:
On Mon, Jul 10, 2017 at 05:10:03PM +0200, Georg-Johann Lay wrote:
Any ideas for a sane approach?

You could change insn_rtx_cost to actually calculate the cost of the
insn, not just set_src_cost of a single set.  This will need checking
on a great many targets, not in the least because most target's cost
functions are, uh, not so good.  Big project, but hopefully well worth
the effort.

I already thought of such an approach by means of a new target hook;
well aware that maintainers are not very fond of new hooks.

Something like so:

Add a new hook that, per default, returns a magic value which indicates
that it is not implemented or that it's too tedious to compute for a
backend.  In that case, SET_DEST is dropped and the usual rtx_cost hook
is run.

If a different value is returned, that value is used for the cost.

The changes would be mostly in rtlanal.c to use cost from that hook
or graceful degrade to classic rtx_cost.

That way, targets could migrate to that hook if they need more exact
cost or SET_DEST or want to dig into PARALLELs. Cf. PR80929.

Just passing a pattern or SET with outer_code = INSN might raise so many
performance degradations across all targets when they would return
some "unknown cost" or make unknown stuff expensive.  Hence passing
outer_code = INSN is not a good idea, except we find someone who is
proficient in all backends' costs and willing to go through that...

After all, what's important is to get best compilation results (at least
if we don'd want to hear even more of the "just switch to xxx compiler:
better code, better diagnostics, better support").

As my 3-liner for PR80929 is already pending review for > 1 month now,
the prospects are not very promising for getting anything like that
to be reviewed...


Or you change your cost function to on a QImode shift assume it is an
insert instruction.  Not correct of course (but neither is the currently
calculated cost), but perhaps it gives good results in practice?

Unlikely.  That machine has no barrel shifter, and when MUL or DIV is
expanded using shifts, exact costs for shifts are needed.

Johann


Segher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]