[patch] RFC: Hook for insn costs (v2)?

[Georg-Johann Lay]

Hi, this is a bit different proposal.  Instead of using some
magic value to indicate that the hook returns nothing useful,
the hook has not a 4th argument of bool* to ship that information.

The goal and usage is the same as with the first proposal:

* Allow the back-end to compute correct costs and to see the
   full pattern.  Reason:  middle-end currently hides parts of
   patterns that might be relevant and implements strange logic
   in some places, e.g. in insn_rtx_costs.

* Don't introduce any performance degradation by changing
   current usage / assumptions of rtx_costs.


Would such a change be in order in principle?

Ideas to improve it?

I would then round it up and propose it as a patch.

Johann



On 12.07.2017 15:15, Georg-Johann Lay wrote:
> Hi,
> 
> the current cost computations in rtlanal.c and maybe other places
> suffer from the fact that they are hiding parts of the expressions
> from the back-end, like SET_DESTs of single_set or the anatomy of
> PARALELLs.
> 
> Would it be in order to have a hook like the one attached?
> 
> I am aware of that, in an ideal world, there wouldn't be more
> than one hook to get rtx costs.  But well...
> 
> Whilst rtx_costs does in the majority of cases, there are cases
> where hiding information leads to performance degradation,
> for example when insn combine cooks up a set zero_extract.
> combine.c does actually the right thing as it uses insn_rtx_costs,
> but insn_rtx_cost is already a lie because it only uses SET_SRC
> and digs into PARALELL without exposing the whole story.
> 
> The patch just uses a new targetm.insn_cost hook.  If the
> back-end doesn't come up with something useful, the classic
> functions with rtx_costs for sub-rtxes are called.
> 
> The purpose is to allow a friendly transition and not no
> raise any performance degradations which would be very likely
> if we just called rtx_costs with outer_code = INSN.
> 
> If a back-end finds it useful to implement this hook and need
> the whole story, they can do so.  Otherwise, or if it is too
> lazy to analyse a specific rtx, they can switch to the old
> infrastructure.
> 
> Returning a magic value for "unknown" is just an implementation
> detail; it could just as well be some bool* that would be set
> to true or false depending on whether or not the computation
> returned something useful or not.
> 
> The patch only touches seq_cost insn_rtx_cost of rtlanal.c.
> 
> Would something like this be in order, or is a new hook just
> a complete no-go?
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: insn-costs-v2.diff
Type: text/x-patch
Size: 4256 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20170713/f40790cb/attachment.bin>