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>