search for: typeless

...com> wrote: > > On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that > we need to uncover and fix between now and the time that typeless pointer > is available. That means it is likely that we have multiple such fixes in > the code and then we have to remove each one of them. (And means each one > of those has to be done properly to be easily remove-able). > > Changing canonicaliztion of memcpy, will be removing a cou...

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 > mind, and I was expecting from David some good indication of a timeframe > for the typeless pointers. > If the typeless pointer work is stalled or if it is not planned for LLVM > 3.9, > It'...

Sorry for my delay responding, finally caught up on my email to this point and read through the whole thread. First and foremost: we should *definitely* not sit on our hands and wait for typeless pointers to arrive. However, we also shouldn't (IMO) take on lots of technical debt instead of working on causing typeless pointers to arrive sooner. But I don't think any of the options here are likely to incur large technical debt, so we should IMO feel free to pursue either approach. I...

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, Mar 22, 2016 at 5:30 PM, David Blaikie <dblaikie at gmail...

OK. I will do some experiments with (1) on Power PC. Will update this email chain about the results. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160323/f05c1bad/attachment.html>

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 forward if the contributor is so inclined/able to shift in that direction." Both "perhaps questionable" and "not outright off limits" seem to strongly imply suc...

...t; llvm-dev at lists.llvm.org > wrote: > > > > > > James, > > > > > > I think (1) reduces the number of "do-not-see-through-bitcast" > > > bugs > > > that we need to uncover and fix between now and the time that > > > typeless pointer is available. That means it is likely that we > > > have > > > multiple such fixes in the code and then we have to remove each > > > one > > > of them. (And means each one of those has to be done properly to > > > be > > > easily remove-...

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 pointer work is stalled or if it is not planned for LLVM 3.9, I agree with Philip to not block anyt...

> On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > James, > > I think (1) reduces the number of "do-not-see-through-bitcast" bugs that we need to uncover and fix between now and the time that typeless pointer is available. That means it is likely that we have multiple such fixes in the code and then we have to remove each one of them. (And means each one of those has to be done properly to be easily remove-able). > > Changing canonicaliztion of memcpy, will be removing a couple of lines o...

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 any development which would be accepted in the typeless pointer work wasn't planned. > > In my view, this is one of th...

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...

...mistaken. I have no specific reason to believe it will be a large amount of work, but prior experience tells me changes to canonical form have a tendency of exposing unexpected issues. To be clear, I am supportive of you implementing solution 1. > > *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, Mar 22, 2016 at 5:30 PM, Da...

...like a simple patch snowballs into a series of mostly minor patches. I'm not trying to warn you off or scare you; I just want to make sure you have reasonable expectations going in. > > Any suggestions? > > > > > > >> *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. >> >>...

...resence of the /type/ information implied by the bitcast should not trip up or be necessary for optimizations (two sides of the same coin)) 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 forward if the contributor is so inclined/able to shift in that direction. But if we're talking about the work to make the optimization not use the type of pointers as a crutch - that...

On Tue, Mar 22, 2016 at 5:44 PM, Ehsan Amiri 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. > It seems to me that the question to ask is what...

...age 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 what's involved here and if David thinks the intermediate steps of handling bit casts everywhere is not making it harder I'm fine with it. -- Mehdi > On Mar 22, 2016, at 12:36 PM, Philip Reames <listmail at philipreames.com> wrote: > >...

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, at 11:32 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > > Back to the discussion on the RFC, I still see some advantage in following th...

...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 what's involved here and if > David thinks the intermediate steps of handling bit casts everywhere > is not making it harder I'm fine with it. It is not clear to me that this is a particularly-large change. As I understand it, we're only talking...

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 kno...

...Tobias Grosser <tobias.grosser at inf.ethz.ch> Subject: Re: [llvm-dev] [RFC] A new multidimensional array indexing intrinsic Hi all, On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Mmmh, looks like Tim Northover is actively working on typeless/opaque > pointers, e.g. https://reviews.llvm.org/D64203 Yep, I'm spending as much time as I can on the project. I think there's not really much chance that it'll be required in this cycle (i.e. when we fork in ~Jan pointers will be distinct IMO). On intrinsics as they affect opaqu...