This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add vector cost model density heuristic
On Mon, 18 Jun 2012, William J. Schmidt wrote:
> On Mon, 2012-06-18 at 13:49 -0500, William J. Schmidt wrote:
> > On Mon, 2012-06-11 at 13:40 +0200, Richard Guenther wrote:
> > > On Fri, 8 Jun 2012, William J. Schmidt wrote:
> > >
> > <snip>
> > >
> > > Hmm. I don't like this patch or its general idea too much. Instead
> > > I'd like us to move more of the cost model detail to the target, giving
> > > it a chance to look at the whole loop before deciding on a cost. ISTR
> > > posting the overall idea at some point, but let me repeat it here instead
> > > of trying to find that e-mail.
> > >
> > > The basic interface of the cost model should be, in targetm.vectorize
> > >
> > > /* Tell the target to start cost analysis of a loop or a basic-block
> > > (if the loop argument is NULL). Returns an opaque pointer to
> > > target-private data. */
> > > void *init_cost (struct loop *loop);
> > >
> > > /* Add cost for N vectorized-stmt-kind statements in vector_mode. */
> > > void add_stmt_cost (void *data, unsigned n,
> > > vectorized-stmt-kind,
> > > enum machine_mode vector_mode);
> > >
> > > /* Tell the target to compute and return the cost of the accumulated
> > > statements and free any target-private data. */
> > > unsigned finish_cost (void *data);
>
> By the way, I don't see much point in passing the void *data around
> here. Too many levels of interfaces that we'd have to pass it around in
> the vectorizer, so it would just sit in a static variable. Might as
> well let the data be wholly private to the target.
Ok, so you'd have void init_cost (struct loop *) and
unsigned finish_cost (void); then? Static variables are of couse
not properly "abstracted" so we can't ever compute two set of costs
at the same time ... but that's true all-over-the-place in GCC ...
With previous discussion the add_stmt_cost hook would be split up
to also allow passing the operation code for example.
Richard.