[llvm-bugs] [Bug 44718] New: Missed optimization: aliasing problem in a struct when a member array is indexed with 64-bit int

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=44718

            Bug ID: 44718
           Summary: Missed optimization: aliasing problem in a struct when
                    a member array is indexed with 64-bit int
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: michel.bernert at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Tested with clang 9.0.0: x86_64-pc-windows-msvc
Compiled with '-O2'.

-----C CODE-----
#include <stdint.h>

struct S {
    uint32_t a;
    uint32_t array[32];
};

uint32_t test1(struct S* ptr, uint32_t index)
{
    ptr->a = 5;
    ptr->array[index] = 4;
    return ptr->a;
}

uint32_t test2(struct S* ptr, uint64_t index)
{
    ptr->a = 5;
    ptr->array[index] = 4;
    return ptr->a;
}
----------------

Produced assembly:
test1:
        mov     dword ptr [rcx], 5
        mov     eax, edx
        mov     dword ptr [rcx + 4*rax + 4], 4
        mov     eax, 5
        ret

test2:
        mov     dword ptr [rcx], 5
        mov     dword ptr [rcx + 4*rdx + 4], 4
        mov     eax, dword ptr [rcx]
        ret


In 'test2', the first store is not forwarded, as if the array store could
overwrite the first member. This doesn't happen in 'test1' where the index is
32-bits.
If I'm not mistaken, any index outside the array range is undefined behaviour,
regardless of the width of the index, so I don't see any reason for a member
store to alias another member.

I also tested with GCC and in both cases the first store is correctly
forwarded.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200130/d1120b63/attachment.html>