[llvm-bugs] [Bug 51975] New: Cost modelling for load-cast

[via llvm-bugs]

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

            Bug ID: 51975
           Summary: Cost modelling for load-cast
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, pengfei.wang at intel.com,
                    spatel+llvm at rotateright.com

We currently don't costmodel the fact that some casts
(mainly sext/zext, but also  nt<->fp) can be folded into the load:
https://godbolt.org/z/vs7sx4nWz

This leads to rather pessimistic cost estimates,
and e.g. potentially affects LV.

Preceding question: does `X86TTIImpl::getCastInstrCost()`
have the right costs for e.g. `sext <8 x i16> to <8 x i32>`?
All `ISD::SIGN_EXTEND` in `AVX2ConversionTbl` are 2+,
for which target is that true?
I'd expect at least the s/zext's to cost 1.

Roughly, i suppose the solution matches that of the LOAD+BSWAP modelling,
i.e. if the cast is a single user of the load, then model it as free,
and when modelling the load which has a single cast user, then do ${MAGIC},

Where ${MAGIC} depends on the answer to the "Preceding question":
if the casts should cost 1, then we only need to adjust the load op sizes,
without increasing the load cost,
else i guess we need to report `max(load cost, cast cost)`?

Does this make sense?

-- 
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/20210926/6e71adf1/attachment-0001.html>