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

[Hal Finkel via llvm-dev]

On 12/23/2017 01:56 PM, Juneyoung Lee via llvm-dev wrote:
> Hello.
> This might be a trivial question, but is it correct if the signal 
> handler aborts the program?

Yes, because the actions of SEGSEGV signal handlers don't fall within 
the abstract machine we're modeling. If they did, we'd need to treat all 
volatile memory accesses as arbitrary function calls (because that's 
exactly what they'd be). This would inhibit our ability to do almost any 
kind of pointer-aliasing reasoning about the volatile accesses (i.e., 
they'd alias with anything that might be visible to an external 
function), and moreover, they'd all be read/write (because that external 
function might do anything).

Another way to look at this is: Once the SEGSEGV is generated, the 
program has already triggered UB (regardless of whether the access is 
volatile and regardless of what the handler might do). This UB is just 
as undefined as any other.

When we've discussed this in the past, I believe the recommendation was 
that, if we want to support a mode in which volatile accesses have these 
kinds of semantics (and there are certainly environments in which this 
might make sense), then we should have Clang lower them into some kind 
of "volatile-access intrinsics" because it will be easy to make these 
look like arbitrary read/write function calls in the optimizer.

  -Hal

> For example:
>
>   int *normal = ADDRESS1;
>   volatile int* ptr = ADDRESS2;
>   int k = *ptr; // segfaults, and the signal handler calls abort()
>   int value = *normal; // this may be UB(undefined behavior).
>
> Let's assume that normal is dereferenceable if ptr1 does not raise 
> SEGSEGV, but accessing normal raises UB if ptr1 raises SEGSEGV.
> Before reordering is done, there's no UB because the program will 
> always abort if UB could happen, but UB may happen after they are 
> reordered.
>
> Best Regards,
> Juneyoung Lee
>
> On Thu, Dec 21, 2017 at 4:50 AM, Krzysztof Parzyszek via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     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
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
> -- 
>
> Juneyoung Lee
> Software Foundation Lab, Seoul National University
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180107/d172501a/attachment.html>