llvm dev - Sep 2012 - [LLVMdev] Proposal: New DAG node type for reciprocal operation

Hi,

 

In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get
more performance when (1) "b" is loop invariant or (2) arch has faster
reciprocal instruction (e.g. recipe/recips on ARM)  or (3) arch has no
vector div, but has vector mul and recip.

 

So ,with this node type, a div node can be converted to a mul and a recip
when desired. Then, each arch can further lower the recip node. Even if the
arch has no recip support, allowing other passes to hoist  "1/b" out
of loop
may still be profitable.

 

It this feasible? 

 

Thanks,

Weiming

 

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120920/34cf2e9b/attachment.html>

Sounds like a reasonable fit for a target-specific DAG combine. I suspect a
target specific node wouldn't be necessary and the patterns could be matched
directly.

-Jim

On Sep 20, 2012, at 3:26 PM, Weiming Zhao <weimingz at codeaurora.org>
wrote:
> Hi,
>  
> In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get
more performance when (1) “b” is loop invariant or (2) arch has faster
reciprocal instruction (e.g. recipe/recips on ARM)  or (3) arch has no vector
div, but has vector mul and recip.
>  
> So ,with this node type, a div node can be converted to a mul and a recip
when desired. Then, each arch can further lower the recip node. Even if the arch
has no recip support, allowing other passes to hoist  “1/b” out of loop may
still be profitable.
>  
> It this feasible?
>  
> Thanks,
> Weiming
>  
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120920/90545c0d/attachment.html>

--- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com> wrote:

From: Jim Grosbach <grosbach at apple.com>
Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation
To: "Weiming Zhao" <weimingz at codeaurora.org>
Cc: llvmdev at cs.uiuc.edu
Date: Thursday, September 20, 2012, 3:32 PM

Sounds like a reasonable fit for a target-specific DAG combine. I suspect a
target specific node wouldn't be necessary and the patterns could be matched
directly.
-Jim
Yes, a target specific node is not necessary, direct pattern matching would be
enough for the required transformation.Having reciprocal node may also give
opportunity for other target specific transformation.
-Shahid
On Sep 20, 2012, at 3:26 PM, Weiming Zhao <weimingz at codeaurora.org>
wrote:
Hi,  In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get
more performance when (1) “b” is loop invariant or (2) arch has faster
reciprocal instruction (e.g. recipe/recips on ARM)  or (3) arch has no vector
div, but has vector mul and recip.  So ,with this node type, a div node can be
converted to a mul and a recip when desired. Then, each arch can further lower
the recip node. Even if the arch has no recip support, allowing other passes to
hoist  “1/b” out of loop may still be profitable.  It this feasible?
 Thanks,Weiming  Qualcomm Innovation Center, Inc. is a member of Code Aurora
Forum, hosted by The Linux Foundation  
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-----Inline Attachment Follows-----

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120920/c9554c00/attachment.html>