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: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
