[cfe-dev] Code generated for pointer pair -> pointer + size -> pointer pair conversion

[Stephan Tolksdorf]

On 19.06.13 22:11, Sean Silva wrote:
> On Sun, Jun 16, 2013 at 4:59 AM, Stephan Tolksdorf <st at quanttec.com
> <mailto:st at quanttec.com>> wrote:
>
>     Hi,
>
>     clang emits the following x64 code for `vector.data() + vector.size()`
>     (where vector is a std::vector<int32> instance that contains two
>     internal pointers that point to the beginning and the end of an array):
>
>        movq  (%rdi), %rcx  // rdi is a pointer to the vector
>        movq  8(%rdi), %rax
>        subq  %rcx, %rax
>        andq  $-4, %rax
>        addq  %rcx, %rax
>
>     Is there any way to tell clang in the vector implementation that the
>     array is aligned, so that it could reduce this code to a simple load
>     `movq 8(%rdi), %rax`?
>
>     This kind of optimization would be helpful for inlined code that
>     converts back and forth between a pointer pair representation and
>     pointer + size representation of an array reference.
>
>
> This is really interesting. It seems we run into a similar problem with:
>
> ArrayRef<int> arrayRefOpt(ArrayRef<int> A) {
>    ArrayRef<int> B(A.data(), A.size());
>    ArrayRef<int> C(B.begin(), B.end());
>    ArrayRef<int> D(C.data(), C.size());
>    ArrayRef<int> E(D.begin(), D.end());
>    ArrayRef<int> F(E.data(), E.size());
>    return D;
> }
>
> Which generates:
> __Z11arrayRefOptN4llvm8ArrayRefIiEE:
>         0:       55                                              pushq
> %rbp
>         1:       48 89 e5                                        movq
>   %rsp, %rbp
>         4:       48 8d 14 b5 00 00 00 00                         leaq
>   (,%rsi,4), %rdx
>         c:       48 c1 fa 02                                     sarq
>   $2, %rdx
>        10:       48 89 f8                                        movq
>   %rdi, %rax
>        13:       5d                                              popq
>   %rbp
>        14:       c3                                              ret

Yeah, that's the reverse direction, where the optimizer doesn't seem to 
know that the upper bits of the array length must be 0 since an array 
length (or any integer added to a pointer) can't be larger than 
SIZE_MAX/sizeof(T).

> Maybe this is bug-report-worthy?

I could submit one, though I'm not sure which product/component to file 
this under.

- Stephan