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

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>

Hi,

On Wed, Dec 20, 2017 at 9:50 AM, Alina Sbirlea <alina.sbirlea at
gmail.com> wrote:
>> 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.
Fwiw, I was under the impression that regular loads could *not* be
reordered with volatile loads since we could have e.g.:

  int *normal = &global_variable;
  volatile int* ptr = 0;
  int k = *ptr; // segfaults, and the signal handler writes to *normal
  int value = *normal;

and that we'd have to treat volatile loads and stores essentially as
calls to unknown functions.

-- Sanjoy

On 12/20/2017 1:37 PM, Sanjoy Das wrote:>
> Fwiw, I was under the impression that regular loads could *not* be
> reordered with volatile loads since we could have e.g.:
> 
>    int *normal = &global_variable;
>    volatile int* ptr = 0;
>    int k = *ptr; // segfaults, and the signal handler writes to *normal
>    int value = *normal;
> 
> and that we'd have to treat volatile loads and stores essentially as
> calls to unknown functions.
For this to work, "normal" should be volatile as well.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation