Re: [PATCH, vec-tails 04/10] Add masking cost

[Jeff Law <law at redhat dot com>]

On 05/20/2016 05:32 AM, Ilya Enkovich wrote:
> 2016-05-20 14:15 GMT+03:00 Richard Biener
> <richard.guenther@gmail.com>:
> > On Fri, May 20, 2016 at 11:44 AM, Ilya Enkovich
> > <enkovich.gnu@gmail.com> wrote:
> > > 2016-05-20 12:24 GMT+03:00 Richard Biener
> > > <richard.guenther@gmail.com>:
> > > > On Thu, May 19, 2016 at 9:40 PM, Ilya Enkovich
> > > > <enkovich.gnu@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > This patch extends vectorizer cost model to include masking
> > > > > cost by adding new cost model locations and new target hook
> > > > > to compute masking cost.
> > > >
> > > > Can you explain a bit why you add separate overall
> > > > masking_prologue/body_cost rather than using the existing
> > > > prologue/body cost for that?
> > >
> > > When I make a decision I need vector loop cost without masking
> > > (what we currently have) and with masking (what I add).  This
> > > allows me to compute profitability for all options (scalar
> > > epilogue, combined epilogue, masked epilogue) and choose one of
> > > them.  Using existing prologue/body cost would allow me compute
> > > masking profitability with no fall back to scalar loop
> > > profitability.
> >
> > Yes, but for this kind of purpose you could simply re-start
> > separate costing via the init_cost hook?
>
> But that would require double scan through loop statements + double
> profitability estimations.  I compute masking cost during statements
> analysis (see patch #05) in parallel with regular costs computations.
> Note that masking costs is a cost of masking only.  Thus cost of a
> vector masked iteration is body cost + body masking cost.
Unless there's some inherent reason not to, I prefer a single scan 
through the loop to compute the costs.  Presumably the cost of the 
epilogue is not derived from the cost of the loop, so we ought to be 
able to build the costs via  single scan.


> > > > I realize that the current vectorizer cost infrastructure is a
> > > > big mess, but isn't it possible to achieve what you did with
> > > > the current add_stmt_cost hook?  (by inspecting stmt_info)
> > >
> > > Cost of a statement and cost of masking a statement are different
> > > things. Two hooks called for the same statement return different
> > > values. I can add vect_cost_for_stmt enum elements to cover
> > > masking but I thought having stmt_masking_cost would me more
> > > clear.
> >
> > I agree we need some kind of overloading and I'm not against a
> > separate hook for this.  On a related note what is "masking cost"
> > here?  I could imagine that masking doesn't unconditionally add a
> > cost to a stmt but its execution cost may now depend on whether an
> > element is masked or not.
> >
> > Does the hook return the cost of the masked stmt or the cost of
> > masking the stmt only (so you need to do add_stmt_cost as well on
> > the same stmt)?
>
> It returns the cost of masking the statement only.  Thus if a
> hardware has no penalty for executing masked instruction then return
> value should be 0.
Probably worth clarifying in the docs/code.

Presumably if there's some kind of micro-architectural cost based on 
prior statements, their masking state, dependencies, etc we'd need a 
more robust API for computing this cost.  But that's probably 
over-engineering at this point.

Jeff