I’m trying to combine multiple memory operands which reference adjacent memory in the Machine IR,
currently i have a store instruction which holds 4 memory operands as a result of merging 4 store instructions from adjacent memory and transferring all of their MemOps into the new instruction ,
this is causing a large increase in compile-time because of al the mayAlias() checks in later passes (mainly when building scheduling DAG).
so i am trying to improve that without losing much performance (or any if possible) due to missing or inaccurate aliasing information,
is there a way to know if it is legal to combine two or more memory operands into one?
if so, is ok to use the first one and just increase its size?
You should create one MMO for the merged access. If it was safe to merge your memory operations, it’s safe to merge the MMOs (you do need to take care to drop metadata that’s now potentially invalid after merging, like range and AA)
You don’t need to simply copy the existing ones you have. You only should use multiple memory operands if you have multiple, disjoint addresses.
As an example, AMDGPU’s SILoadStoreOptimizer does this: llvm-project/SILoadStoreOptimizer.cpp at 36e24da8eb56f8e68e2874305d3ea0e59d37f7b8 · llvm/llvm-project · GitHub
Your case may be much simpler if you don’t care about address spaces.
is it correct to do the merge even if the machine memory operands are not related?
for example i have 2 variables allocated on the stack:
%cnt = alloca i32, align 4
%lookup_temp = alloca i32, align 4
store i32 %call, i32* %lookup_temp, align 4, !tbaa !7
store i32 0, i32* %cnt, align 4, !tbaa !7
and after Prologue/Epilogue Insertion & Frame Finalization i have:
fi#0: size=4, align=4, at location [SP-8]
fi#1: size=4, align=4, at location [SP-4]
memory info for first store: (store (s32) into %ir.lookup_temp, !tbaa !7)
memory info for second store:(store (s32) into %ir.cnt, !tbaa !7)
the two store instructions can be combined because they are allocated on adjacent memory on the stack
and i’m not sure if it is correct merge the two into: (store (s64) into %ir.cnt)
am i missing something, is there a need for special handling for memory operands referencing the stack?
This is a bit of an unusual case. I do not think you should combine these while preserving the underlying IR value in the memory operand. You can simply drop it. It might be an option to use a FixedStack PseudoSourceValue instead