llvm dev - Dec 2017 - Hoisting in the presence of volatile loads.

Hi Krzysztof,

Could I get some background info on reasoning about hoisting in the
presence of volatile loads?
I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll

Context: MemorySSA treats volatile loads as defs. I'm looking to better
understand expected behavior in the presence of volatile accesses.
More context: https://reviews.llvm.org/D40375.

Thanks in advance,
Alina
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171219/ebbf37b4/attachment.html>

MemorySSA disambiguates volatile loads even though it treats them as defs.
see test/Analysis/MemorySSA/volatile-clobber.ll

Last discussion was https://reviews.llvm.org/D16875


On Tue, Dec 19, 2017 at 5:14 PM, Alina Sbirlea <alina.sbirlea at
gmail.com>
wrote:
> Hi Krzysztof,
>
> Could I get some background info on reasoning about hoisting in the
> presence of volatile loads?
> I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll
>
> Context: MemorySSA treats volatile loads as defs. I'm looking to better
> understand expected behavior in the presence of volatile accesses.
> More context: https://reviews.llvm.org/D40375.
>
> Thanks in advance,
> Alina
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171219/bf6a9fa9/attachment.html>

Hi Alina,
The testcase was inspired by a situation that a customer reported to us 
a while back.
There was a function taking two pointers, one was used to load something 
from device-mapped memory (volatile), while the other was accessing 
regular memory.  These two pointers were aliased (in LLVM), but not 
because they were proven to alias, but because they weren't proved to be 
different.
However, according to the C rules, accessing a volatile object through a 
non-volatile pointer results in an undefined behavior, so we could have 
assumed that the program was well-formed and thus that the pointers 
didn't alias after all.
In the end, what was important was that the loop was running as fast as 
possible, and any invariant code should have been moved out of it.  The 
non-volatile load was not (because of how AliasSetTracker was treating 
volatile loads), and the customer reported it to us as a missed 
performance opportunity.

-Krzysztof

On 12/19/2017 7:14 PM, Alina Sbirlea wrote:
> Hi Krzysztof,
> 
> Could I get some background info on reasoning about hoisting in the 
> presence of volatile loads?
> I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll
> 
> Context: MemorySSA treats volatile loads as defs. I'm looking to better
> understand expected behavior in the presence of volatile accesses.
> More context: https://reviews.llvm.org/D40375.
> 
> Thanks in advance,
> Alina
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Daniel,
Thanks a lot for the pointer, that's very helpful! I'll use that as a
guide
to update how we handle volatile accesses.
Mind if I ask for feedback when I update the patch?

Krzysztof,
Thanks for the answer, that was very informative! I appreciate it!

Best,
Alina

On Wed, Dec 20, 2017 at 5:33 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> Hi Alina,
> The testcase was inspired by a situation that a customer reported to us a
> while back.
> There was a function taking two pointers, one was used to load something
> from device-mapped memory (volatile), while the other was accessing regular
> memory.  These two pointers were aliased (in LLVM), but not because they
> were proven to alias, but because they weren't proved to be different.
> However, according to the C rules, accessing a volatile object through a
> non-volatile pointer results in an undefined behavior, so we could have
> assumed that the program was well-formed and thus that the pointers
didn't
> alias after all.
> In the end, what was important was that the loop was running as fast as
> possible, and any invariant code should have been moved out of it.  The
> non-volatile load was not (because of how AliasSetTracker was treating
> volatile loads), and the customer reported it to us as a missed performance
> opportunity.
>
> -Krzysztof
>
>
> On 12/19/2017 7:14 PM, Alina Sbirlea wrote:
>
>> Hi Krzysztof,
>>
>> Could I get some background info on reasoning about hoisting in the
>> presence of volatile loads?
>> I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll
>>
>> Context: MemorySSA treats volatile loads as defs. I'm looking to
better
>> understand expected behavior in the presence of volatile accesses.
>> More context: https://reviews.llvm.org/D40375.
>>
>> Thanks in advance,
>> Alina
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171220/acbadba3/attachment.html>