Hal Finkel via llvm-dev
2016-Feb-25 06:56 UTC
[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
----- Original Message -----> From: "Sanjoy Das" <sanjoy at playingwithpointers.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > Sent: Thursday, February 25, 2016 12:25:54 AM > Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") > > > Hal Finkel wrote: > > > But it is not all optimizations that are the problem. Rather, it > > seems like a select few (e.g. things involving collapsing allowed > > non-determinism in atomics), and losing those optimizations seems > > better than generally losing function-attribute deduction. > > If we go by the langref, then optimizations that fold undef are also > problematic (though most C/C++ programs resulting in such IR would > have UB in practice).If the undef is folded to some concrete value (instead of just being propagated), then yes, I agree. We really should be propagating the undef, however, right?> > I think there are non-(non-deterministic) problematic cases too. The > following won't happen today since `readnone` does not imply > `safe_to_speculate`, but if we add a `safe_to_speculate` property > some > day: > > int foo(bool C) available_externally { > if (C) > ((int *) null)++; // UB > ret 42; > } > > void bar() { > if (<some cond>) > foo(true); > } > > Now, normally you can just delete the `if (C)` branch in foo, and it > would become just a `ret 42`, and would look like it is speculatable > above the `<some cond>` check. But if you then link with an -O0 > version, you'll have introduced UB if `<some cond>` is always false > at > runtime.So this is a good point, but I'm not sure how much to generalize this example. When we add a safe_to_speculate attribute, we'll need to keep this in mind (special care must be taken in such non-definitive-definition contexts). -Hal> > Today this won't happen since we don't speculate `readnone nounwind` > functions, but could become a problem in the future. > > -- Sanjoy >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Chandler Carruth via llvm-dev
2016-Feb-25 07:12 UTC
[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
On Wed, Feb 24, 2016 at 10:56 PM Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Sanjoy Das" <sanjoy at playingwithpointers.com> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Chandler Carruth" <chandlerc at google.com>, "llvm-dev" < > llvm-dev at lists.llvm.org>, "Philip Reames" > > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" < > dexonsmith at apple.com> > > Sent: Thursday, February 25, 2016 12:25:54 AM > > Subject: Re: [llvm-dev] Possible soundness issue with > available_externally (split from "RFC: Add guard intrinsics") > > > > > > Hal Finkel wrote: > > > > > But it is not all optimizations that are the problem. Rather, it > > > seems like a select few (e.g. things involving collapsing allowed > > > non-determinism in atomics), and losing those optimizations seems > > > better than generally losing function-attribute deduction. > > > > If we go by the langref, then optimizations that fold undef are also > > problematic (though most C/C++ programs resulting in such IR would > > have UB in practice). > > If the undef is folded to some concrete value (instead of just being > propagated), then yes, I agree. We really should be propagating the undef, > however, right? >But we're allowed to fold it. And we do fold it to a concrete identity value in an operand of some operation all the time. Or as a function call argument. Or ... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160225/fa578b0d/attachment.html>
Hal Finkel via llvm-dev
2016-Feb-25 07:35 UTC
[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
----- Original Message -----> From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" <listmail at philipreames.com>, "Duncan P. N. Exon Smith" > <dexonsmith at apple.com> > Sent: Thursday, February 25, 2016 1:12:45 AM > Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics") > > > > > On Wed, Feb 24, 2016 at 10:56 PM Hal Finkel < hfinkel at anl.gov > > wrote: > > > ----- Original Message ----- > > From: "Sanjoy Das" < sanjoy at playingwithpointers.com > > > To: "Hal Finkel" < hfinkel at anl.gov > > > Cc: "Chandler Carruth" < chandlerc at google.com >, "llvm-dev" < > > llvm-dev at lists.llvm.org >, "Philip Reames" > > < listmail at philipreames.com >, "Duncan P. N. Exon Smith" < > > dexonsmith at apple.com > > > Sent: Thursday, February 25, 2016 12:25:54 AM > > Subject: Re: [llvm-dev] Possible soundness issue with > > available_externally (split from "RFC: Add guard intrinsics") > > > > > > Hal Finkel wrote: > > > > > But it is not all optimizations that are the problem. Rather, it > > > seems like a select few (e.g. things involving collapsing allowed > > > non-determinism in atomics), and losing those optimizations seems > > > better than generally losing function-attribute deduction. > > > > If we go by the langref, then optimizations that fold undef are > > also > > problematic (though most C/C++ programs resulting in such IR would > > have UB in practice). > > If the undef is folded to some concrete value (instead of just being > propagated), then yes, I agree. We really should be propagating the > undef, however, right? > > > > But we're allowed to fold it.Apparently not as allowed as we thought. ;)> And we do fold it to a concrete > identity value in an operand of some operation all the time. Or as a > function call argument. Or ...Define "all the time"? We get undefs from actual undefined behavior at the language level, from "don't cares" in shuffle masks, etc. and it seems easy to construct cases where a function's readonlyness depends on how you fold the undef, but it is not clear that, in itself, this is problematic. -Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Apparently Analagous Threads
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")