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: [patch] RFC: Hook for insn costs?


On Wed, Aug 02, 2017 at 12:56:58PM -0700, Richard Henderson wrote:
> On 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> > I'm not sure if that's a good or a bad thing.  Currently the mid-end
> > depends on some rtx constructs having sensible costs even if there's no
> > rtl pattern to match them (IIRC plus:QI is one such construct - RISC
> > type machines usually lack such an instruction). 
> 
> I hadn't considered this... but there are several possible workarounds.
> 
> The simplest of which is to fall back to using rtx_cost if the insn_cost hook
> returns a failure indication, e.g. -1.
> 
> > Also, costs tend to be
> > micro-architecture specific so attaching costs directly to patterns
> > would be extremely painful, adding support would require touching the
> > entirety of the MD files.  The best bet would be a level of indirection
> > from the patterns to cost tables, much like scheduler attributes.
> 
> I was never thinking of adding costs directly to the md files, but rather
> structuring the insn_cost hook like
> 
>   if (recog_memoized (insn) < 0)
>     return -1;
>   switch (get_attr_type (insn))
>     {
>     case TYPE_iadd:
>     case TYPE_ilog:
>     case TYPE_mvi:
>       return COSTS_N_INSNS (1);
> 
>     case TYPE_fadd:
>       return cost_data->fp_add;
>     }
> 
> etc.  This would be especially important when it comes costing for simd-type
> insns.  Matching many of those any other way would be fraught with peril.

I tried prototyping something like this for AArch64 a while back - it
feels like the only sensible, scalable and maintainable way to rationalise
the costs code. Anything else drifts from the md file over time, and is
a tangled mess of spaghetti code to implement a poor-quality recog clone.

I ran in to exactly the problem Richard Earnshaw mentions above - too
many partial rtx fragments came in that I couldn't recognise. The points
in the compilation pipeline where I could receive an RTX to cost meant that
I could get be asked for costs before recog was correctly initialised.

I think a clean hook which operated in this way would be a great step
forward for the RTX costs.

Thanks,
James


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