[llvm-commits] [llvm] r166865 - /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp

[Hal Finkel]

----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Nadav Rotem" <nrotem at apple.com>, llvm-commits at cs.uiuc.edu
> Sent: Monday, October 29, 2012 11:52:55 AM
> Subject: Re: [llvm-commits] [llvm] r166865 - /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp
> 
> Hi Hal,
> 
> >> does this mean you are querying target lowering info to get these
> >> cost
> >> estimates? That doesn't make any sense to me.
> >>
> >>
> >> Yes. We ask TLI if the operation is legal (or custom or promote)
> >> or
> >> if it is 'expand'. This works in many cases.
> >> The idea is to provide a basic cost information for all targets.
> >> The
> >> cost information that we get is inaccurate, but it gives us a
> >> ballpark figure.
> >> The next step is to define backend-specific cost model that will
> >> give
> >> more accurate information.
> >>
> >>
> >>
> >> Can't the whole cost
> >> estimate thing be its own independent world?
> >
> > It could be, but then we'd need to maintain two separate sets of
> > target-dependent information,
> 
> not necessarily, since codegen could also query this.  For example,
> the IR
> transforms need to know whether a certain vector operation is cheap.
>  To know
> this, you need to know what the target machine is, what features are
> enabled
> etc.  All this could be factored out of codegen into some
> library/interface that
> is shared both by the IR level and by codegen.  As far as I can see
> this isn't
> what is being done, please correct me if I'm wrong.
> 

You're correct. To do as you suggest, we would essentially need to refactor all of the targets so that the stuff inside the constructors of *ISelLowering, and some associated subtarget classes, is moved into a separate set of libraries that will be used both by CodeGen and by the IR-level optimizers (through some abstract interface). I am not sure the benefit is worth all of the associated work, but I don't object.

 -Hal

> Ciao, Duncan.
> 
>   a lot of which will be redundant. The existing targets already give
>   us 80% of
> what we need (what types are legal, what operations are legal, how
> these things
> are legalized, etc.), and we get this for all targets without doing
> any
> additional work. To get beyond legalization costs, target-specific
> tables and
> code will be needed, and keeping all of the target-dependent code
> together seems
> like it makes the most sense.
> >
> > Thanks again,
> > Hal
> >
> >>
> >>
> >> I don't understand this.
> >>
> >>
> >> In fact it would be nice
> >> to have cost information for all targets regardless of whether
> >> codegen
> >> support for that target is even built (but maybe that's going too
> >> far).
> >>
> >> I agree. This is what I want to get with the default
> >> implementation.
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>
> >
> 
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory