[PATCH] "float2int": Add a new pass to demote from float to int where possible.
chisophugis at gmail.com
Wed Mar 18 17:18:44 PDT 2015
On Thu, Mar 5, 2015 at 7:36 AM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:
> In http://reviews.llvm.org/D7790#134758, @mkuper wrote:
> > Hi James,
> > Just so we have a record of what we talked about on IRC (and can give
> Hal a chance to disagree :-)
> Good; I disagree :-)
> The first question is answer is: What is the most useful and reasonable
> canonical form? The reason I support running this pass early in the
> pipeline is because I believe that demoting these int -> fp -> int
> sequences to int sequences, when semantically equivalent, is the most
> useful canonical form.
> If it is useful, because of microarchitectural features, to use FP vector
> ops instead of integer vector ops, then that should be 'actively' handled
> later (instead of just taking advantage of it when it happens to happen).
Actually, the opposite transformation might be useful in any backend and is
not limited to vector ops. Currently, extremely integer-heavy workloads
(there are many applications that fall into this category, e.g. LLVM
itself) end up leaving all the floating point units idle regardless of
architecture. So it's just a matter of the relative domain-crossing costs
vs. the extra ILP due to having more execution resources. On architectures
like x86 that have a memory-->register int to FP conversion instruction,
some of the domain crossing cost can be avoided. A cursory look at the
wikipedia page for POWER8 indicates that the core has 2x integer units, but
7 other units that can do basic arithmetic (4x FPU, 2x VMX, 1x Decimal FP).
-- Sean Silva
> So I think that this should run early by default, x86 included. We should
> also reverse the transformation later, perhaps within the vectorizer, using
> an actual cost model, if that proves useful.
> > On x86, vector i64 muls can be much worse than vector double muls. Since
> this is pre-LoopV, and we don't know if we'll end up with vector or scalar
> code, I think the safe thing to do on x86 would be to disable this for
> cases where we'll do a double -> i64 transformation.
> > This means we should probably have a target hook for that that x86 can
> rL LLVM
> EMAIL PREFERENCES
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits