similar to: RFC: Allow readnone and readonly functions to throw exceptions

On Tue, Jan 3, 2017 at 10:47 AM, Michael Kuperstein via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Jan 3, 2017 at 9:59 AM, Sanjoy Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Michael, >> >> On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein >> <michael.kuperstein at gmail.com> wrote: >> > This

On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: > I just realized that there's an annoying corner case to this scheme -- > I can't DSE stores across readnone maythrow function calls because the > exception handler could read memory. That is, in: > > try { > *a = 10; > call void @readnone_mayunwind_fn(); > *a = 20; > } catch (...) { >

Hi Michael, On Mon, Jan 2, 2017 at 11:49 PM, Michael Kuperstein <michael.kuperstein at gmail.com> wrote: > This sounds right to me. > > IIUC, historically, readonly and readnone are meant to model the "pure" and > "const" GCC attributes. These attributes make pretty strong guarantees: > > "[a pure] function can be subject to common subexpression

On 01/05/2017 03:10 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I don't understand why that's desirable, and I think it would > severely limit our ability to infer these attributes for functions > that unwind. You'd need to prove things -- likely

On 01/05/2017 12:17 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 01/05/2017 10:55 AM, Sanjoy Das wrote: > > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel

On 01/05/2017 10:55 AM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 6:12 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> On 01/04/2017 10:35 PM, Sanjoy Das via llvm-dev wrote: >>> I just realized that there's an annoying corner case to this scheme -- >>> I can't DSE stores across readnone maythrow function calls because the >>>

On 01/05/2017 01:20 PM, Sanjoy Das wrote: > Hi Hal, > > On Thu, Jan 5, 2017 at 11:10 AM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is still only a function of its arguments, so it can be CSE'd. > That's a good example -- we can CSE it without worrying about the > memory state flowing in. > > In fact, if we have: > > *a =

On 01/05/2017 12:45 PM, Mehdi Amini wrote: > >> On Jan 5, 2017, at 10:39 AM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> On 01/05/2017 12:17 PM, Reid Kleckner wrote: >>> On Thu, Jan 5, 2017 at 9:19 AM, Hal Finkel via llvm-dev >>> <llvm-dev at lists.llvm.org

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

Dear All, Are functions marked as readnone or readonly in the LLVM IR allowed to generate output or to exhibit exceptional behavior (e.g., calling abort(), generating an MMU fault, etc.)? The SAFECode compiler has a set of run-time checks that pass or fail based solely on the input arguments and, in some cases, global state. They do not modify a program's global state, but they do print

On 6/21/12 2:23 AM, Duncan Sands wrote: > Hi John, > >> Are functions marked as readnone or readonly in the LLVM IR allowed to >> generate output or to exhibit exceptional behavior (e.g., calling >> abort(), generating an MMU fault, etc.)? > they are allowed to unwind exceptions for example, since in theory this > can occur without scrunching externally visible memory

Hi John, > Are functions marked as readnone or readonly in the LLVM IR allowed to > generate output or to exhibit exceptional behavior (e.g., calling > abort(), generating an MMU fault, etc.)? they are allowed to unwind exceptions for example, since in theory this can occur without scrunching externally visible memory (for example unwinding can be done by having functions return an

On 23 May 2014 09:42, Robert Lougher <rob.lougher at gmail.com> wrote: > Hi Nick, > > Thanks for replying. Bug filed: > http://llvm.org/bugs/show_bug.cgi?id=19842 Thank you! Strangely enough, my first conclusion was that %p was being marked > readnone incorrectly as it wasn't handling the copy via @get_addr. > Sorry -- saying %p alone is ambiguous because

Hi, I'm investigating a bug which I have so far been able to narrow down to the following small testcase: ======== test.c =========== int *get_pntr(int *p) { return p; } __attribute__((noinline)) void store(int *p) { int *p2 = get_pntr(p); *p2 = 10; } int test() { int i; store(&i); return i; } ----------------------------- If this is compiled in two steps as

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

Confirmed, this is a bug. This define i32* @get_pntr(i32* %p) nounwind uwtable { entry: ret i32* %p } define void @store(i32* %p) noinline nounwind uwtable { entry: %call = call i32* @get_pntr(i32* %p) store i32 10, i32* %call, align 4 ret void } run through opt -functionattrs gets a 'readnone' on @store's %p. That's wrong, it clearly stores to it. The bug is due to

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

Hi Andy, Thanks for replying, responses inline below: On Fri, Feb 19, 2016 at 11:12 AM, Andrew Trick <atrick at apple.com> wrote: > This clearly doesn't need operand bundles, but using an intrinsic > would permit special code motion semantics. It could be hoisted and > merged with other traps, but the condition could never be widened > beyond the union of the original

On 05/21/2014 02:52 PM, Robert Lougher wrote: > On 21 May 2014 21:40, Robert Lougher <rob.lougher at gmail.com> wrote: >> define i32* @get_pntr(i32* readnone %p) { >> entry: >> ret i32* %p >> } >> >> define void @store(i32* nocapture readnone %p) { >> entry: >> store i32 10, i32* %p, align 4, !tbaa !1 >> ret void >> }

Hello, I'm in a situation where my code is calling many native functions. Sometimes, these calls are simply calls to static "accessor" methods that read a variable in some class object (object pointer as input, member variable value returned as output). I was wondering if using the setOnlyReadsMemory method on the native function objects could help LLVM generate optimized code