similar to: RFC: Opaque pointer status and future direction

>> So at a high level I think we should put the serialization and Instruction >> changes in sooner rather than later, giving us a largely undocumented[2] dialect >> of IR with opaque pointers that we can write tests against to upstream the rest >> of what I've done (and others can use to continue work in parallel if they're >> inclined). > > My,

Hi, In the past months, several options have been presented for making byval (and similar attributes, such as inalloca or sret) work with opaque pointers. The main two I've seen were byval(T) and byval(N) where N is the size of T. They both have their upsides and downsides, for example: byval(T) would be a type-parametric attribute, which, AFAIK, does not already exist and may complicate

> Do all tests need it? Align is just for non-default alignment (> align(1)) so it may be OK for the tests to omit it & it's probably not right to /require/ an align attribute on a byval parameter. I've had to fix some of the tests which checked that the right alignment was applied, by looking at the generated asm, but had no "align A" attributes and relied on the

> pointers. If you're writing a front-end this probably means you need > to keep your AST's representation of element types alongside LLVM > pointer Values in your own data-structures Yeah, that’s no problem - the type is needed for signed/unsigned integer distinctions anyway. There’s no getting around having one’s own type hierarchy. >> And also - is it possible to use

On Mon, Mar 9, 2015 at 12:38 PM, Reid Kleckner <rnk at google.com> wrote: > If we're keeping types on GEP, > You mean rather than just dropping gep entirely & doing manual pointer arithmetic? (& moving inbounds to an attribute on pointer addition, I guess?) > then IMO we should keep them on allocas and globals. It keeps the IR human > readable. > & what of

Moving this to llvm-dev where I should've sent it in the first place (& +Chandler, because we discussed this offline a bit) On Thu, Feb 19, 2015 at 11:32 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 19, 2015 at 10:57 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Thu, Feb 19, 2015 at 8:31 AM, Rafael Espíndola <

2016-01-20 1:11 GMT+02:00 Antoine Pitrou via llvm-dev < llvm-dev at lists.llvm.org>: > On Wed, 20 Jan 2016 00:47:56 +0200 > "Eddy B. via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > > > > I would love to know your thoughts on this, and more specifically: > > Which of the 3 (byval(T), byval(N) and byval + dereferenceable + align) > > do you

Some frontends for LLVM require that LLVM perform tail call optimization (TCO) for correctness. Internally, LLVM refers to TCO of a non-recursive tail call as sibling call optimization, but I'm going to refer to that generically as TCO. Often, functional languages like Scheme have a language-level requirement that TCO occurs for any call in the tail position, and this is usually why users of

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

Hello all, A few years ago, I added the inalloca feature to LLVM IR so that Clang could be C++ ABI compatible with MSVC on 32-bit x86. The feature works, but there is room for improvement. I recently took the time to write up a design using token values that will hopefully be better named and easier to work with and around. For the technical details of the proposal, I've written up the RFC

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

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,

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 wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll

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 was looking at the talk from 2015 about opaque pointers. Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other way to perpare for this change? And also - is it possible to use something like opaque pointers (that is using a single pointer type) even before the switch has been flipped in LLVM? Christoffer AEGIK / www.aegik.se

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

On Feb 17, 2015, at 1:58 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > I'm not actually worried about this change though Chris, at least w.r.t. optimizer changes being necessary. There are a few reasons: > > 1) The old ScalarRepl pass cared a *lot* about pointer type, but the new SROA doesn't care at all, so the biggest offender is essentially handled. Why do you

On Tue, Feb 17, 2015 at 10:47 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Feb 17, 2015 at 10:27 PM, Chris Lattner <clattner at apple.com> > wrote: > >> On Feb 17, 2015, at 1:58 PM, Chandler Carruth <chandlerc at gmail.com> >> wrote: >> > I'm not actually worried about this change though Chris, at least >> w.r.t.

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