[llvm-dev] Hoisting in the presence of volatile loads.

[Alina Sbirlea via llvm-dev]

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>