llvm dev - Dec 2017 - TypeExpandInteger for vectors?

On Dec 11, 2017 6:54 PM, "Sean Silva" <chisophugis at gmail.com>
wrote:

It looks like in various places in SelectionDAG and related machinery we
appear to implicitly or explicitly assume that TypeExpandInteger only
applies to scalars.

Does anybody know why that is?

For our target (Pixel Visual Core: https://www.blog.google/
products/pixel/pixel-visual-core-image-processing-and-
machine-learning-pixel-2/) expanding a N-bit vector op into two (N/2)-bit
vector ops


To be clear: the vector ops are all of the same number of elements. Just
the bit width of the element type changes.

is a natural way to legalize some of our vector operations, but we're
finding that we need to modify a bunch of random places in the code to make
it work. I'm curious if there is a cleaner way, or some big picture thing
I'm missing.

Thanks,

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/e4503aa2/attachment.html>

On 12/12/2017 7:26 AM, Sean Silva via llvm-dev wrote:
>
>
> On Dec 11, 2017 6:54 PM, "Sean Silva" <chisophugis at
gmail.com
> <mailto:chisophugis at gmail.com>> wrote:
>
>     It looks like in various places in SelectionDAG and related
>     machinery we appear to implicitly or explicitly assume that
>     TypeExpandInteger only applies to scalars.
>
>     Does anybody know why that is?
>
>     For our target (Pixel Visual Core:
>    
https://www.blog.google/products/pixel/pixel-visual-core-image-processing-and-machine-learning-pixel-2/
>    
<https://www.blog.google/products/pixel/pixel-visual-core-image-processing-and-machine-learning-pixel-2/>)
>     expanding a N-bit vector op into two (N/2)-bit vector ops
>
>
> To be clear: the vector ops are all of the same number of elements. 
> Just the bit width of the element type changes.
I think it just hasn't been a priority for any in-tree target; most code 
doesn't use illegal vector types much, and the default strategy 
generates decent code in most cases.  (You might have an easier time 
just adding a few target-specific DAGCombines for specific operations 
which lead to low-quality code.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171212/6fb09a7c/attachment.html>

Thanks Eli. Good idea of using DAG combines for this, I'll see if that
works for us.

-- Sean Silva

On Tue, Dec 12, 2017 at 12:22 PM, Friedman, Eli <efriedma at
codeaurora.org>
wrote:
> On 12/12/2017 7:26 AM, Sean Silva via llvm-dev wrote:
>
>
>
> On Dec 11, 2017 6:54 PM, "Sean Silva" <chisophugis at
gmail.com> wrote:
>
> It looks like in various places in SelectionDAG and related machinery we
> appear to implicitly or explicitly assume that TypeExpandInteger only
> applies to scalars.
>
> Does anybody know why that is?
>
> For our target (Pixel Visual Core: https://www.blog.google/
> products/pixel/pixel-visual-core-image-processing-and-machin
> e-learning-pixel-2/) expanding a N-bit vector op into two (N/2)-bit
> vector ops
>
>
> To be clear: the vector ops are all of the same number of elements. Just
> the bit width of the element type changes.
>
>
> I think it just hasn't been a priority for any in-tree target; most
code
> doesn't use illegal vector types much, and the default strategy
generates
> decent code in most cases.  (You might have an easier time just adding a
> few target-specific DAGCombines for specific operations which lead to
> low-quality code.)
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171213/57584b09/attachment.html>