[llvm-bugs] [Bug 46048] New: [X86][SSE] Improve constant pool loading to balance folding/broadcast/vzload

[via llvm-bugs]

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

            Bug ID: 46048
           Summary: [X86][SSE] Improve constant pool loading to balance
                    folding/broadcast/vzload
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm-dev at redking.me.uk
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com
          See Also: https://bugs.llvm.org/show_bug.cgi?id=30585

As Craig suggested on D80131:

> Ideally we'd have a way to fold vzext_load ops inside
> X86InstrInfo::foldMemoryOperandCustom (by zero padding the constant pool
> entry where necessary) but I'm not certain how easy that is.

I think the caller of foldMemoryOperandImpl is responsible for copying the
memoperand over to the new instruction. So changing the memory reference out
from under it will break that at the very least. We'd also be deferring our
usual load folding to the peephole pass which isn't as quite strong as
SelectionDAG I think.

If the load is in a loop we potentialy unfold it in MachineLICM and hoist it
out of the loop. So maybe what we really want is a later constant pool
shrinking pass that runs after Machine LICM. We have a similar issue with
broadcasts from constant pool don't we? Lowing of build_vector favors forming
broadcasts of constants without knowing if we can fold.

-- 
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/20200523/67bbe3c2/attachment-0001.html>