http://llvm.org/bugs/show_bug.cgi?id=8408
Summary: Taking top half of vector gives lshr instead of
shufflevector
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Created an attachment (id=5630)
--> (http://llvm.org/bugs/attachment.cgi?id=5630)
C source for get_low_half and get_high_half
In gethalf.c there are some inline functions to take the bottom or the
top half of a vector by using a C union. I translated to LLVM assembler
code like this:
clang -cc1 gethalf.c -emit-llvm -o gethalf0.ll
clang -cc1 gethalf.c -emit-llvm -o gethalf3.ll -O3
If you want to try this without Clang:
opt -O3 gethalf0.ll -S -o gethalf3.ll
In gethalf3.ll you can see that after optimisation get_low_half turns
into a simple shufflevector:
%tmp7.i = shufflevector <32 x i16> %srcval, <32 x i16> undef, <16 x i32> <i32
0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32
11, i32 12, i32 13, i32 14, i32 15>
However, get_high_half turns into an lshr on a giant i512:
%tmp9.i = bitcast <32 x i16> %srcval to i512
%tmp6.i = lshr i512 %tmp9.i, 256
%tmp7.i = trunc i512 %tmp6.i to i256
%tmp8.i = bitcast i256 %tmp7.i to <16 x i16>
This is correct, as far as I can tell, but not very helpful, I think.
Also, the different treatment of the two cases seems inconsistent.
I think they should probably both turn into a shufflevector.
Tested at revision 116700.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
