[llvm-dev] GlobalISel legalization guarantees

[Friedman, Eli via llvm-dev]

On 7/19/2017 2:08 PM, Tim Northover via llvm-dev wrote:
> =========================================
> Expanded description of test-suite issues
> =========================================
>
> G_STORE and G_EXTRACT
> ---------------------
>
> These are instances of a merge feeding legal instructions. I believe this has to
> be permitted but it means that selection is going to contend with a wide range
> of possible different merge instructions. At best all legal input and output
> register classes must be handled.
>
> On AArch64 the likely list is:
>
>    + "mov vD.2d[0], dN; mov vD.2d[1], dM" (and s variants with 4 insts).
>    + "mov vD.4s[0], wN, ..." (and d variants).
>    + "ubfi xD, xN, #0, #32; ubfi xD, xM, #32, #32"
>    + "COPY; COPY; COPY" or multiples of the above when stitching together a QQQ.

You can use a stack temporary for all of these, and worry about 
optimizing it later.

>
> Machine intrinsics
> ------------------
>
> The versions of this problem I've seen come from code like this::
>
>    {<2 x i32>, <2 x i32>, <2 x i32>} %val = call {...} @llvm.aarch64.ld3(%ptr)
>    %vec0 = extractelement {...} %val, 1
>
> which becomes::
>
>    s192 = G_INTRINSIC_W_SIDE_EFFECTS ...
>    s64, s64, s64 = G_UNMERGE_VALUES s192

Instead of keeping this form through legalization, could we just fix the 
intrinsic to return its natural type?

-Eli

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