similar to: [LLVMdev] Moving towards a singular pointer type

On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Did this work ever get done? There was a long thread about it back in 2015. > > I wish to use IRBuilder. > Is there any documentation? > How do I use the singular pointer type in GEP, LOAD, STORE instructions? > Sorry, no, the work is not complete - for

On Mon, Feb 16, 2015 at 3:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 6, 2015, at 3:38 PM, David Blaikie <dblaikie at gmail.com> wrote: > > It's an idea been thrown around in a few different threads (including > Rafael's recent > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html > and Chandler's

I imagine/assume that distinct pointer types per address space are still necessary, but I haven't looked at address spaces in any particular detail. On Feb 8, 2015 1:13 AM, "Kuperstein, Michael M" < michael.m.kuperstein at intel.com> wrote: > One reservation about this being “singular” - we are still going to have > a different pointer type per address space, right?

BTW are we planning to also remove gep 0 after we would have typeless pointers? I saw the David's presentation year ago but I am not sure if it was mentioned. If it would be removed, then does it mean that SROA would still need some new code to handle it (assuming it doesn't handle bitcasts right now) Here is the patch solving my issue https://reviews.llvm.org/D28126 2016-12-25 13:40

On Tue, Mar 22, 2016 at 1:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Sorry I should have been more clear (writing to many email in parallel) > > You're right. I was adding a +1 to you here. > > Especially I wrote "unless there is an acknowledgement that typeless > pointers won't be there before a couple of years" with the PassManager in >

I don't really mind, but the intermediate stage will not be very nice: that a lot of code / tests that needs to be written with bitcast, and all of that while they are deemed to disappear. The added value isn't clear to me considering the added work. I'm not sure it wouldn't add more work for all the cleanup required by the "typeless pointer", but I'm not sure

I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block any development which would be accepted in the typeless pointer work wasn't planned. In my view, this is one of the largest

But not what David was stating, unless I misread? I was specifically responding to David's wording: "If we're talking about making an optimization able to ignore the bitcast instructions - yes, that work is unnecessary & perhaps questionable given the typeless pointer work. Not outright off limits, but the same time might be better invested in moving typeless pointers

This is roughly what I wrote... > On Mar 22, 2016, at 1:31 PM, Philip Reames <listmail at philipreames.com> wrote: > > I feel very strongly that blocking work on making optimization bitcast-ignorant on the typeless pointer work would be a major mistake. Unless we expected the typeless pointer work to be concluded within the near term (say 3-6 months maximum), we should not block

I don't know enough about the tradeoff for 1, but 2 seems like a bandaid for something that is not a correctness issue neither a regression. I'm not sure it justifies "bandaid patches" while there is a clear path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. -- Mehdi > On Mar 22, 2016,

On Wed, Mar 16, 2016 at 11:00 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > David, > > Could you give us an update on the status of typeless pointer work? How > much work is left and when you think it might be ready? > It's a bit of an onion peel, really - since it will eventually involve generalizing/fixing every optimization that's currently leaning on typed

2016-12-24 9:39 GMT+01:00 Chandler Carruth <chandlerc at google.com>: > On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > > On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

Thanks. *Phillip, *As Hal said I do not think (1) is a very large item. Please let me know if I am mistaken. *David *I think (1) is more inline with typeless pointer work than (2). Contributing to typeless pointer work will be great, but given its unknown time frame we cannot stop fixing existing problems. Of course, we should follow an approach consistent with the long-term solution. On Tue,

Back to the discussion on the RFC, I still see some advantage in following the proposed solution. I see two paths forward: 1- Change canonical form, possibly lower memcpy to non-integer load and store in InstCombine. Then teach the backends to convert that to integer load and store if that is more profitable. Notice that we are talking about loads that have no use other than store. So it is a

Ultimately everything is going to be made to not rely on the types of pointers - that's nearly equivalent to bitcast-ignorant (the difference being that the presence of an extra instruction (the bitcast) might trip up some optimizations - but the presence of the /type/ information implied by the bitcast should not trip up or be necessary for optimizations (two sides of the same coin)) If

Sorry I should have been more clear (writing to many email in parallel) You're right. I was adding a +1 to you here. Especially I wrote "unless there is an acknowledgement that typeless pointers won't be there before a couple of years" with the PassManager in mind, and I was expecting from David some good indication of a timeframe for the typeless pointers. If the typeless

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Philip Reames" <listmail at philipreames.com>, "David Blaikie" > <dblaikie at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, uweigand at de.ibm.com, "Tom > Stellard" <thomas.stellard at

On Wed, Mar 16, 2016 at 8:34 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > How do it interact with the "typeless pointers" work? > Right - the goal of the typeless pointer work is to fix all these bugs related to "didn't look through bitcasts" in optimizations. Sometimes that's going to mean more work (because the code

I'd phrase this differently: being pointer-bitcast agnostic is a step towards support typeless pointers. :) We can either become bitcast agnostic all in one big change or incrementally. Personally, I'd prefer the later since it reduces the risk associated with enabling typeless pointers in the end. Philip On 03/22/2016 12:16 PM, Mehdi Amini via llvm-dev wrote: > I don't know

On Fri, Dec 23, 2016 at 10:17 PM Daniel Berlin <dberlin at dberlin.org> wrote: On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com> wrote: On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: 2016-12-23