similar to: [LLVMdev] Is address space 1 reserved?

> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 01/07/2015 11:52 AM, Matt Arsenault wrote: >> >>> On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com <mailto:resistor at mac.com>> wrote: >>> >>> I'm not aware of any such restriction, and I know of several LLVM based systems

> On Jan 7, 2015, at 2:25 PM, Owen Anderson <resistor at mac.com> wrote: > > I'm not aware of any such restriction, and I know of several LLVM based systems that use address space 1 for something other than that. > > -Owen Yes, this would be a problem for us. We use 1 for a normal address space where 0 is invalid. However, we also have a problem where some other address

On 01/07/2015 12:17 PM, Pete Cooper wrote: > >> On Jan 7, 2015, at 12:05 PM, Matt Arsenault <arsenm2 at gmail.com >> <mailto:arsenm2 at gmail.com>> wrote: >> >> >>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com >>> <mailto:listmail at philipreames.com>> wrote: >>> >>> >>> On

> On Jan 7, 2015, at 3:10 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 01/07/2015 12:05 PM, Matt Arsenault wrote: >> >>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: >>> >>> >>> On 01/07/2015 11:52 AM, Matt Arsenault wrote:

On 1/8/2015 1:55 AM, Philip Reames wrote: >>>> I think the problems aren’t so much that accessing 0 doesn’t work >>>> (although I imagine there are problems with that), but expectations >>>> of comparison with null. The main problem I’m aware of is >>>> comparisons with null pointers. The first global object in >>>> addrspace(3) will

On Wed, Jul 1, 2015 at 2:10 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I'd be interested in an updated summary as well, especially any thoughts > you have on when the various pieces might come online and where extra hands > could be helpful; we're eager to build our EH support in LLILC on top of > this. > A preliminary step was

On 06/26/2015 08:42 AM, David Majnemer wrote: > > > On Fri, Jun 26, 2015 at 7:00 AM, Paweł Bylica <chfast at gmail.com > <mailto:chfast at gmail.com>> wrote: > > Hi, > > Let's have a simple program: > define i32 @main(i32 %n, i64 %idx) { > %idxSafe = trunc i64 %idx to i5 > %r = extractelement <4 x i32> <i32 -1, i32

On Tue, Jun 9, 2015 at 12:32 PM, David Majnemer <david.majnemer at gmail.com> wrote: > 'load volatile i32 addrspace(1)* null' seems fine to me. However, it > looks like instcombine will turn: > define i32 @foo() { > entry: > %std_ld.i = load volatile i32, i32 addrspace(1)* null > ret i32 %std_ld.i > } > > into: > define i32 @foo() { > entry:

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result

Inline. From: Philip Reames [mailto:listmail at philipreames.com] Sent: Thursday, August 27, 2015 11:01 AM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at

Thanks David, It turns out, that the address space I was using was not 0, and yet the pointer was constant folded to null. Here is the sequence: Unoptimized code: define i32 @foo() #0 { entry: %address.addr.i = alloca i32, align 4 %value.i = alloca i32, align 4 store i32 0, i32* %address.addr.i, align 4 %0 = load i32* %address.addr.i, align 4 %1 = inttoptr i32 %0 to i32 addrspace(1)*

On 15 Feb 2014, at 23:55, Andrew Trick <atrick at apple.com> wrote: > On Feb 14, 2014, at 5:18 PM, Philip Reames <listmail at philipreames.com> wrote: > >> RFC: GEP as canonical form for pointer addressing >> >> I would like to propose that we designate GEPs as the canonical form for pointer addressing in LLVM IR before CodeGenPrepare. >> >>

Philip: I think there are two separate issues: 1) Handling GC pointers stored in stack locations -- tracking their liveness, reporting them to the GC. etc. 2) Treating pointers to stack locations as GC-pointers. I think the two options that you presented here are for solving (1). I'm trying to solve issue (2) using alloca in addrspace(1). Basically, we want to create a pointer to a stack

> -----Original Message----- > From: Philip Reames [mailto:listmail at philipreames.com] > Sent: Friday, August 28, 2015 9:38 AM > To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm- > dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers > <andya at

On 02/17/2014 02:53 PM, Andrew Trick wrote: > On Feb 17, 2014, at 2:31 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 15 Feb 2014, at 23:55, Andrew Trick <atrick at apple.com> wrote: >> >>> On Feb 14, 2014, at 5:18 PM, Philip Reames <listmail at philipreames.com> wrote: >>> >>>> RFC: GEP as canonical form for

On 12/14/2013 05:18 PM, Dan Gohman wrote: > On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > > On Dec 12, 2013, at 4:57 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > >> undef + any == NaN (since undef can be NaN) or undef +

Please see inline. From: Chandler Carruth [mailto:chandlerc at google.com] Sent: Wednesday, August 26, 2015 7:03 PM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Philip Reames <listmail at philipreames.com>; Sanjoy Das <sanjoy at playingwithpointers.com> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for

Great, thank you! On Wed, Aug 31, 2016 at 2:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Chris Sakalis" <chrissakalis at gmail.com> > *To: *"Daniel Berlin" <dberlin at dberlin.org> > *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "David Majnemer" < > david.majnemer

Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead? - CL > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com> wrote: > >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote: >> Hi all, >> >> Say we have this IR: >> >> %1 = icmp slt i16 %x, 0

Thank you for the quick fix, I can no longer reproduce the issue. As far a releases go, I am guessing that this is going to be in 4.0? Best, Chris On Tue, Aug 30, 2016 at 9:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > Yeah, i just hope it doesn't regress scatter/gather vector code badly. > But at least it's correct now? > > > On Tue, Aug 30, 2016 at 1:11