SelectionDAG.cpp: FindOptimalMemOpLowering behavior

Project Infrastructure LLVM Dev List Archives
#1

Hi all,

I’m have a question about the behavior of the “FindOptimalMemOpLowering” function.
It is mentioned that this function only need to look at the “DstAlign” and not the “SrcAlign” because “SrcAlign” is always greater than “DstAlign”.
But if “DstAlign” is equal to zero and “SrcAlign” to one the condition is respected. But in this case, wouldn’t we want to take “SrcAlign” into account instead of “DstAlign”.

I have a code where the source is a buffer of bytes (aligned on 1-byte for my backend), and a destination which is the stack, which is seen by LLVM as an object which alignment can change (SelectionDAG.cpp: getMemcpyLoadsAndStores), and so “DstAlign” is set to zero.

At the end, I have a memcpy which is inlined, the stores are well aligned with the stack, but the loads are aligned on MVT:i64 because the “SrcAlign” was not taken into account in “FindOptimalMemOpLowering”.

I have the default implementation of the “getOptimalMemOpType”.

Can someone tell me if I’m misunderstanding the behavior of this function, or if there is something to fix.

Thanks,
Romaric

#2

Hi Romaric,

I did some work in this area recently. Just In case you haven’t noticed it yet: I have first moved FindOptimalMemOpLowering to TargetTransformInfo (https://reviews.llvm.org/D59766) so that it can be reused. I added a function getMemcpyCost to TTI (https://reviews.llvm.org/D59252), which I implement in the ARM backend (https://reviews.llvm.org/D59787), which uses this FindOptimalMemOpLowering to determine the cost of a memcpy.
My goal is to optimise the case shown in the description of https://reviews.llvm.org/D59129, which sounds similar to the problem you’re having.

I’ve looked at that condition too that you are referring to. Some assumptions are made, and I thought there was room for improvement. But I didn’t want to change too much at the same time while I was refactoring it, but it was still on my list to look at this again some time later. That’s why I can’t comment further on details at this point, but will see what I can do.

Cheers,
Sjoerd.