search for: ptr_a

On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > However, I didn't quite understand your point about may-throw -- how > > is may-throw different from a generic side-effect (volatile store, > > syscall etc.)? All of those can't be hoisted or sunk -- we have to >

...tructions after a security-critical check has failed is not always a good thing to do) so I agree that it’s a good idea to avoid depending on it. > So we'd > have to do repeat the null checks in the unwind block, like > > superblock: # unwinds to unwind_block > null_check(ptr_a) > do_something > null_check(ptr_b) > do_something_again > > unwind_block: > ;; either ptr_a is null or ptr_b is null > if (ptr_a == null) > throw_nullptrexception(bci = 42) > else ;; if (ptr_b == null) > throw_nullptrexception(bci = 43) &...

...calls with EH/abnormal edges), volatile inline assembly in the bitmap of blocks specified by BLOCKS or to the whole CFG if BLOCKS is zero. ... The goal is to expose cases in which entering a basic block does not imply that all subsequent instructions must be executed. */ > // ptr_a and ptr_b are NoAlias, ptr_a holds 0 to begin with. > > ThreadA: > while(true) { store volatile i32 42, i32* %ptr_b } > store atomic i32 42, i32* %ptr_a > > ThreadB: > %val = load atomic i32, i32* %ptr_a > assert(%val is not 42) // The store is "guarded" b...

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++ -Xclang -femit-debug-entry-values -O2 -ggdb test.cpp For this case-- these Tags are not emitted DW_TAG_call_site, DW_TAG_call_site_paramter .. only DW_AT_GNU_all_call_sites attribute is present. + @Djorde...

...label %endif.2 ] label.1: ; preds = %entry br label %switchexit label.3: ; preds = %entry br label %then.2 switchexit: ; preds = %label.1, %entry %ptr_b.0 = phi int* [ %data_d, %label.1 ], [ null, %entry ] ; <int*> [#uses=1] br label %endif.2 then.2: ; preds = %label.3, %entry %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry ] ; <int*> [#uses=1] store int 0, int* %ptr_a.1.0 br label %then.3 endif.2: ; preds = %switchexit, %entry %ptr_b.0.1 = phi int* [ %ptr_b.0, %switchexit ], [ %data_b, %entry ] ; <int*> [#uses=2] %tmp.12 = seteq int* %ptr_b.0...

...ry > br label %then.2 > > switchexit: ; preds = %label.1, %entry > %ptr_b.0 = phi int* [ %data_d, %label.1 ], [ null, %entry ] ; > <int*> [#uses=1] > br label %endif.2 > > then.2: ; preds = %label.3, %entry > %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry > ] ; <int*> [#uses=1] > store int 0, int* %ptr_a.1.0 > br label %then.3 > > endif.2: ; preds = %switchexit, %entry > %ptr_b.0.1 = phi int* [ %ptr_b.0, %switchexit ]...

...;>>> %ptr_b.0 = phi int* [ %data_d, %label.1 ], [ null, %entry ] ; > >>>> <int*> [#uses=1] > >>>> br label %endif.2 > >>>> > >>>> then.2: ; preds = %label.3, %entry > >>>> %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry > >>>> ] ; <int*> [#uses=1] > >>>> store int 0, int* %ptr_a.1.0 > >>>> br label %then.3 > >>>> > >>>> endif.2: ; pre...

I won’t be able to attend, but I’d be interested in hearing if any conclusions are reached on several of these topics: > On 16 Oct 2015, at 21:27, Joe Ranieri via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > - Dealing with the explosion of basic blocks that come up with > languages where almost every function call, implicit and explicit, can > raise exceptions. This

...* [ %data_d, %label.1 ], [ null, %entry ] ; > >>>>>> <int*> [#uses=1] > >>>>>> br label %endif.2 > >>>>>> > >>>>>> then.2: ; preds = %label.3, %entry > >>>>>> %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry > >>>>>> ] ; <int*> [#uses=1] > >>>>>> store int 0, int* %ptr_a.1.0 > >>>>>> br label %then.3 > >>>>>> > >>>&g...

...abel.1 ], [ null, %entry ] ; >>>>>>>> <int*> [#uses=1] >>>>>>>> br label %endif.2 >>>>>>>> >>>>>>>> then.2: ; preds = %label.3, %entry >>>>>>>> %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry >>>>>>>> ] ; <int*> [#uses=1] >>>>>>>> store int 0, int* %ptr_a.1.0 >>>>>>>> br label %then.3 >>>>>>>> >&gt...

...%ptr_b.0 = phi int* [ %data_d, %label.1 ], [ null, %entry ] ; >>>>>> <int*> [#uses=1] >>>>>> br label %endif.2 >>>>>> >>>>>> then.2: ; preds = %label.3, %entry >>>>>> %ptr_a.1.0 = phi int* [ %data_f, %label.3 ], [ %data_e, %entry >>>>>> ] ; <int*> [#uses=1] >>>>>> store int 0, int* %ptr_a.1.0 >>>>>> br label %then.3 >>>>>> >>>>>> endif.2:...

...This therefore returns nullptr > from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL > and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. Why is noalias not valid here? I thought LLVM's notion of noalias was based on data dependence -- ptr_a does not alias ptr_b if a store to ptr_a does not have a data dependence with a load from ptr_b and vice versa (and for a zero-sized allocation there can be no data dependence since there cannot legally be such a load/store). Is the C++ notion of noalias different? > > To put this in code,...

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

...>> from Allocate, but that method is marked with LLVM_ATTRIBUTE_RETURNS_NONNULL >> and LLVM_ATTRIBUTE_RETURNS_NOALIAS, both of which aren’t true in this case. > > Why is noalias not valid here? > > I thought LLVM's notion of noalias was based on data dependence -- > ptr_a does not alias ptr_b if a store to ptr_a does not have a data > dependence with a load from ptr_b and vice versa (and for a zero-sized > allocation there can be no data dependence since there cannot legally > be such a load/store). Is the C++ notion of noalias different? That was an assum...

> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end. > Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to > the DW_AT_call_all_calls. > > There is also

> On Mar 24, 2016, at 12:45 PM, Xiangyang Guo via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes

Hi, When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set,