[llvm-bugs] [Bug 43864] New: Suboptimal codegen for storing std::pair<std::uint32_t, std::uint32_t>

[via llvm-bugs]

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

            Bug ID: 43864
           Summary: Suboptimal codegen for storing
                    std::pair<std::uint32_t, std::uint32_t>
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++17
          Assignee: unassignedclangbugs at nondot.org
          Reporter: denis.yaroshevskij at gmail.com
                CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
                    llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

When storing a pair<uint32_t, uint32_t> (and probably similar types) it is
significantly faster to first shift two ints together and then do one bigger
store (according to my measurements - up to two times for uint32_t).

However, clang at the moment for std::pair does two moves. When doing shifts in
code by hand, clang does not modify them back (even though in other cases I can
clearly see that it perfectly understands how to switch between shifts and
moves)

Can clang generate shifts + 1 store for pairs instead of two stores?

>>>>>>>>>>
Data:

Note: uint_tuple is a template magic that stores uints into a bigger uint.


Benchmark:
populate a vector of a 1000 pairs. pairs look like pair<uint8_t, uint8_t>, ,
pair<uint16_t, uint16_t>, - up to 64. Alternative - same pair but into a one
bigger integer.


Godbolt with codegen for different operations:
https://gcc.godbolt.org/z/GKf7lE

Mesurement results:
Quick-Bench: http://quick-bench.com/aDq3iN3dpi9VWQc8XSd6o7Hlzl4
My machine: https://denisyaroshevskiy.github.io/algorithm_dumpster/#uint_tuple


>>>>>>>>>

P.S. trunk gcc does something new when storing pairs:
https://gcc.godbolt.org/z/Zbz96a

-- 
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/20191031/f95a33b5/attachment.html>