search for: ispointerintrinsicallyinvalid

...ll someone with UB that they're Doing It Wrong. Of the two options, I still think the second is a non-starter. Something between the two might be a datalayout flag specifying addrspace(0) behaviour. It's pretty easy to argue that it'd be good if code used some kind of "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of thing anyway (rename or relocate at will). And the name really is terrible, we should change it if at all feasible Tim.

On 4/18/2018 11:21 AM, Tim Northover via cfe-dev wrote: > On 18 April 2018 at 18:13, Manoj Gupta via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> Therefore, I would like to implement support for this flag (maybe with a >> different name), > I'd suggest -mdo-what-i-mean; the whole idea is horribly > underspecified, and basically rips up the LangRef in favour of

...g. > > Of the two options, I still think the second is a non-starter. > Something between the two might be a datalayout flag specifying > addrspace(0) behaviour. It's pretty easy to argue that it'd be good if > code used some kind of > "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of > thing anyway (rename or relocate at will). > > And the name really is terrible, we should change it if at all > feasible > > > > On Wed, Apr 18, 2018 at 1:46 PM Jon Chesterfield via llvm-dev > <llvm-dev at lists.llvm.org &...

...#39;re Doing It Wrong. > > Of the two options, I still think the second is a non-starter. > Something between the two might be a datalayout flag specifying > addrspace(0) behaviour. It's pretty easy to argue that it'd be good if > code used some kind of > "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of > thing anyway (rename or relocate at will). > > And the name really is terrible, we should change it if at all feasible On Wed, Apr 18, 2018 at 1:46 PM Jon Chesterfield via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I'm working with an...

I'm working with an embedded architecture that could, in some situations, run faster if code or data could be located at address zero. I don't know whether this applies to other embedded chips. Despite the name, the flag actually has rather straightforward semantics > from the compiler's perspective. From the gcc docs for > -fdelete-null-pointer-checks: "Assume that

...ptions, I still think the second is a non-starter. >> Something between the two might be a datalayout flag specifying >> addrspace(0) behaviour. It's pretty easy to argue that it'd be >> good if >> code used some kind of >> "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of >> thing anyway (rename or relocate at will). >> >> And the name really is terrible, we should change it if at all >> feasible >> >> >> >> On Wed, Apr 18, 2018 at 1:46 PM Jon Chesterfield via llvm-dev >&...

...for implementing the feature. > Of the two options, I still think the second is a non-starter. Something between the two might be a datalayout flag specifying > addrspace(0) behaviour. It's pretty easy to argue that it'd be good if > code used some kind of > "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of > thing anyway (rename or relocate at will) Whether or not this is put into DataLayout, moving all the null-related addrSpace != 0 checks into an accessor seems like a great idea. Besides this feature request, presumably there's also other uses of non-zero a...

...gt;> >> Of the two options, I still think the second is a non-starter. >> Something between the two might be a datalayout flag specifying >> addrspace(0) behaviour. It's pretty easy to argue that it'd be good if >> code used some kind of >> "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of >> thing anyway (rename or relocate at will). >> >> And the name really is terrible, we should change it if at all feasible > > > > On Wed, Apr 18, 2018 at 1:46 PM Jon Chesterfield via llvm-dev < > llvm-dev at lists.llvm.org> wr...