llvm dev - May 2019 - SelectionDAG.cpp: FindOptimalMemOpLowering behavior

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190516/ce466fb4/attachment.html>

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.



________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Romaric
Jodin via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 16 May 2019 13:26
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] SelectionDAG.cpp: FindOptimalMemOpLowering behavior

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190516/840531a1/attachment-0001.html>