similar to: RFC: Adding a !thread.private metadata

Thanks, Richard. Based on the feedback from this thread, I'll move forward with the patches for nofree, nosync, adding a new corresponding dereferenceable attribute (my suggestion is to name this dereferenceable_on_entry; suggestions welcome), and updating Clang is emit this new attribute instead of the current one.  -Hal On 07/11/2018 06:43 PM, Richard Smith wrote: > On Wed, 11 Jul 2018

Hi, everyone, I'd like to propose adding a nofree function attribute to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Clang/LLVM can currently misoptimize functions that:  1. Have a reference argument.  2. Free the memory backing the object to which the reference is bound during the function's

[+Richard] On 07/11/2018 08:29 AM, Sanjoy Das wrote: > I'm not sure if nosynch is sufficient. What if we had: > > void f(int& x) { > if (false) { > int r0 = x; > } > } > > // other thread > free(<pointer to x>); > > The source program is race free, but LLVM may speculate the read from > x (seeing that it is dereferenceable) creating a

On 02/19, Juneyoung Lee via llvm-dev wrote: > Hello, > > > Would it be correct to resolve this by saying that dereferenceable(N) > > *implies* not_poison? This would be helpful as a clarification of how > > it all fits together. > > Yes, I think it makes sense. I don't we should do that. Take the `gep inbounds` example: char* foo(char *arg) { return `gep

The second equality here: (in lib/Bitcode/Reader/BitcodeReader.cpp) AtomicOrdering Ordering = GetDecodedOrdering(Record[OpNum+2]); if (Ordering == NotAtomic || Ordering == Release || Ordering == AcquireRelease) return Error("Invalid STOREATOMIC record"); Is failing on this assembly, which was generated by Clang: store atomic i32 0, i32* @mutex release,

2017-04-05 18:30 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On Mon, Apr 3, 2017 at 2:01 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > >> I don't see any way to model it right now in LLVM, but I see a one > simple > >> solution: > >> add extra information to the metadata nodes indicating that

2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>: > > > 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > >> Hi Piotr, >> >> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski >> (piotr.padlewski at gmail.com) wrote: >> > [snip] >> > Do I understand it correctly, that it is legal to

2017-04-06 17:57 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On April 6, 2017 at 2:36:53 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > I disagree, I find it different than the patch you mentioned. We don't > have > > any problems with code like this: > > > > ptr = load i8*, i8** %ptrptr,

Hi all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void

On Sat, Sep 17, 2011 at 1:00 PM, David Meyer <pdox at google.com> wrote: > The second equality here: (in lib/Bitcode/Reader/BitcodeReader.cpp) > >      AtomicOrdering Ordering = GetDecodedOrdering(Record[OpNum+2]); >      if (Ordering == NotAtomic || Ordering == Release || >          Ordering == AcquireRelease) >        return Error("Invalid STOREATOMIC record");

I left a comment on https://reviews.llvm.org/D18738 earlier which I feel is related to this discussion, so I'm reproducing it here: I wonder though if what we want to express isn't some sort of "type-based dereferencability annotations". For example the semantics I care about are essentially, "if you know you have a defereferencable pointer, you can go and dereference any

David provided one good answer. I'll give another. The current design pushes complexity into the language frontend for - as far as I know - no good reason. I can say from recent experience that the corner cases around atomics are both surprising and result in odd looking hacks in the frontend. To say this differently, why should marking loads and stores atomic required me to rewrite

Hi all, I am new to llvm. Does llvm has support for openmp directives like #pragma openmp threadprivate(var)? If so does the variable 'var' can be class objects instead of Plain Old Datatypes (POD) like int, float etc. g++ allows the #pragma openmp threadprivate(var) primitive only for the POD type. Please check the bug link at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 . Please

I'd like to propose that we add an attribute which expresses the notion that the specified value is /either/ null or dereferenceable up to a fixed size. (Note the xor.) Our current dereferenceable(n) attribute doesn't quite fit the bill, it implies that the pointer is non-null. Similarly, our nonnull attribute says nothing about dereferenceability. There are two syntax proposals

On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Piotr, > > On March 31, 2017 at 9:07:42 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > Hi all, > > I have a question about dereferenceable metadata on load instruction. I > > have a patch (https://reviews.llvm.org/D31539) for LICM that hoists >

Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global

Hi, I've been looking at improving atomicrmw & cmpxchg code more, particularly on architectures using the load-linked/store-conditional model. The summary is that current expansion for cmpxchg seems to happen too late for LLVM to make meaningful use of the opportunities it provides. I'd like to move it earlier and express it in terms of a first-class pair of "load linked"

Hi Piotr, On March 31, 2017 at 1:07:12 PM, Piotr Padlewski (piotr.padlewski at gmail.com) wrote: > [snip] > Do I understand it correctly, that it is legal to do the hoist because all > of the instructions above %vtable does not throw? Yes, I think you're right.  HeaderMayThrow is a conservative approximation, and the conservativeness is biting us here. > Are there any plans to

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return