On Tue, Jul 11, 2017 at 11:14:20AM +0200, Georg-Johann Lay wrote: > 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.
The big problem is that RTX costs are used for two different things. They are used for getting a cost (estimate) for computing any random expression, but they also are used for getting a cost for something that is already known to be a valid machine instruction. For most targets computing the latter would be much simpler and more exact if we had a separate hook for it. But we also still need the former. Perhaps we can teach GCC to not need that, or, if insn cost is separated from expression cost computing the expression cost could be cheaper as well. > After all, what's important is to get best compilation results Yes exactly! And there is no quick fix I'm afraid. For example, something as obvious as costing a PARALLEL as the maximum cost of any of its branches, regresses various targets. > 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... Okay, I'll go find it. I cannot okay it but I can review it :-) > >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. No quick fixes :-( Segher
