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 < >> rafael.espindola at gmail.com> wrote: >> >>> Long term I would love to remove byval and sret. With inalloca the >>> outgoing frame is explicit a the IR and we just have loads and stores. >>> >>> A short term idea would be to add just the size to the byval. That >>> should be sufficient, no? >> >> > I like this idea! >So do I. Chandler had some other thoughts that I'll attempt to express here: * When you get right down to it, byval seems rather similar to alloca and global variables (they're all just some number of bytes with a required alignment) * If we're changing byval should we change alloca and/or globals, too? (I'm a bit more of a pragmatist in this domain, and I'm not /too/ fussed about changing the one that's tricky (byval) and leaving the other two) * We could just change their IR APIs to take a type but lower to bytes+alignment - textual/bitcode would be all size+alignment, but the C++ APIs for creating these constructs would still allow the user to pass in a type as a convenience. (Chandler suggested possibly keeping the textual IR allowing types to be specified - but the bitcode to be size+alignment, and deserializing that into a [i8 x N], but just supporting the C++ API seems sufficient to me but I hadn't thought of that in my conversation with him) This does reflect part of the point of typeless pointers: that memory isn't typed, it's just bytes (and alignment). Globals, allocas, and byvals are all just that. Does any of this sound important/reasonable?> > >> I was going to agree - but poking around, it looks like we need alignment >> too, at least (not sure if we need other things beyond size & alignment, >> nothing springs to mind but I don't know much about this stuff) - >> TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment >> > > Nope, we don't, we have an align attribute. =D >Yep, seemed the align attribute wasn't always set in the frontend (& there's a comment in the backend where getByValTypeAlignment is called saying essentially "this is a fallback, it's not always correct, frontends should emit an align attribute if this isn't the behavior they want"). But PPC32 is the only one using a complex implementation of this function, everyone else, if they use it at all (which I think might be NVPTX and some others) just uses the default, which is the llvm::Type's alignment. I'm working on moving this sort of thing to clang. The auto-upgrade might be a bit annoying, though (as we'll have to keep a bunch of that fallback logic around, but at least it'll just be in the auto-upgrader?) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/d7fb4d52/attachment.html>
If we're keeping types on GEP, then IMO we should keep them on allocas and globals. It keeps the IR human readable. We're pretty close to mandatory data layout, so computing the size and alignment of these things when they aren't explicitly specified should be easy. On Mon, Mar 9, 2015 at 9:57 AM, David Blaikie <dblaikie at gmail.com> wrote:> 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 < >>> rafael.espindola at gmail.com> wrote: >>> >>>> Long term I would love to remove byval and sret. With inalloca the >>>> outgoing frame is explicit a the IR and we just have loads and stores. >>>> >>>> A short term idea would be to add just the size to the byval. That >>>> should be sufficient, no? >>> >>> >> I like this idea! >> > > So do I. > > Chandler had some other thoughts that I'll attempt to express here: > > * When you get right down to it, byval seems rather similar to alloca and > global variables (they're all just some number of bytes with a required > alignment) > * If we're changing byval should we change alloca and/or globals, too? > (I'm a bit more of a pragmatist in this domain, and I'm not /too/ fussed > about changing the one that's tricky (byval) and leaving the other two) > * We could just change their IR APIs to take a type but lower to > bytes+alignment - textual/bitcode would be all size+alignment, but the C++ > APIs for creating these constructs would still allow the user to pass in a > type as a convenience. (Chandler suggested possibly keeping the textual IR > allowing types to be specified - but the bitcode to be size+alignment, and > deserializing that into a [i8 x N], but just supporting the C++ API seems > sufficient to me but I hadn't thought of that in my conversation with him) > > This does reflect part of the point of typeless pointers: that memory > isn't typed, it's just bytes (and alignment). Globals, allocas, and byvals > are all just that. > > Does any of this sound important/reasonable? > > >> >> >>> I was going to agree - but poking around, it looks like we need >>> alignment too, at least (not sure if we need other things beyond size & >>> alignment, nothing springs to mind but I don't know much about this stuff) >>> - TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment >>> >> >> Nope, we don't, we have an align attribute. =D >> > > Yep, seemed the align attribute wasn't always set in the frontend (& > there's a comment in the backend where getByValTypeAlignment is called > saying essentially "this is a fallback, it's not always correct, frontends > should emit an align attribute if this isn't the behavior they want"). But > PPC32 is the only one using a complex implementation of this function, > everyone else, if they use it at all (which I think might be NVPTX and some > others) just uses the default, which is the llvm::Type's alignment. > > I'm working on moving this sort of thing to clang. The auto-upgrade might > be a bit annoying, though (as we'll have to keep a bunch of that fallback > logic around, but at least it'll just be in the auto-upgrader?) > > - David >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/b98290b3/attachment.html>
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 byval, then? Do you agree with Chandler's argument from analogy between byval, alloca, and globals? (oh, and I should look at inalloca a bit too - it looks like it uses the getByValTypeAlignment too... ) - David> > We're pretty close to mandatory data layout, so computing the size and > alignment of these things when they aren't explicitly specified should be > easy. > > On Mon, Mar 9, 2015 at 9:57 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> 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 < >>>> rafael.espindola at gmail.com> wrote: >>>> >>>>> Long term I would love to remove byval and sret. With inalloca the >>>>> outgoing frame is explicit a the IR and we just have loads and stores. >>>>> >>>>> A short term idea would be to add just the size to the byval. That >>>>> should be sufficient, no? >>>> >>>> >>> I like this idea! >>> >> >> So do I. >> >> Chandler had some other thoughts that I'll attempt to express here: >> >> * When you get right down to it, byval seems rather similar to alloca and >> global variables (they're all just some number of bytes with a required >> alignment) >> * If we're changing byval should we change alloca and/or globals, too? >> (I'm a bit more of a pragmatist in this domain, and I'm not /too/ fussed >> about changing the one that's tricky (byval) and leaving the other two) >> * We could just change their IR APIs to take a type but lower to >> bytes+alignment - textual/bitcode would be all size+alignment, but the C++ >> APIs for creating these constructs would still allow the user to pass in a >> type as a convenience. (Chandler suggested possibly keeping the textual IR >> allowing types to be specified - but the bitcode to be size+alignment, and >> deserializing that into a [i8 x N], but just supporting the C++ API seems >> sufficient to me but I hadn't thought of that in my conversation with him) >> >> This does reflect part of the point of typeless pointers: that memory >> isn't typed, it's just bytes (and alignment). Globals, allocas, and byvals >> are all just that. >> >> Does any of this sound important/reasonable? >> >> >>> >>> >>>> I was going to agree - but poking around, it looks like we need >>>> alignment too, at least (not sure if we need other things beyond size & >>>> alignment, nothing springs to mind but I don't know much about this stuff) >>>> - TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment >>>> >>> >>> Nope, we don't, we have an align attribute. =D >>> >> >> Yep, seemed the align attribute wasn't always set in the frontend (& >> there's a comment in the backend where getByValTypeAlignment is called >> saying essentially "this is a fallback, it's not always correct, frontends >> should emit an align attribute if this isn't the behavior they want"). But >> PPC32 is the only one using a complex implementation of this function, >> everyone else, if they use it at all (which I think might be NVPTX and some >> others) just uses the default, which is the llvm::Type's alignment. >> >> I'm working on moving this sort of thing to clang. The auto-upgrade might >> be a bit annoying, though (as we'll have to keep a bunch of that fallback >> logic around, but at least it'll just be in the auto-upgrader?) >> >> - David >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/871cfa55/attachment.html>