Moving this to llvm-dev where I should’ve sent it in the first place (& +Chandler, because we discussed this offline a bit)
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.
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
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?)
Yep. If we're keeping the GEP sugar to say, "hey this pointer arithmetic is
actually trying to access field #4", then we should keep the allocation
sugar that says "these 4 bytes are (usually) an i32."
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... )
byval and inalloca are edge cases where we can afford to sacrifice some
readability.
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?)Yep. If we're keeping the GEP sugar to say, "hey this pointer arithmetic
is actually trying to access field #4", then we should keep the allocation
sugar that says "these 4 bytes are (usually) an i32."
*nod*
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... )byval and inalloca are edge cases where we can afford to sacrifice some
readability.
I'm pretty comfortable with that perspective - but I'll leave this out here
in case others (including Chandler) want to chime in & clarify/delve/etc.
(I'm working on GEP operators in the mean time anyway, so I'm not
immediately blocked on this)
So, inalloca, maybe.
But I don't see why byval is more or less relevant than anything else here.
If it makes sense to keep the type is a convenience for readabie IR and
such in 'alloca' (and I agree that it does), I feel like it makes sense for
byval as well.
Sure, I'd like to keep the type for both for readability, but I don't think
it's worth adding support for attributes that can reference Types.
Another thing to think about is that llvm.memcpy calls today aren't typed,
and we aren't trying to change that. byval is just a hidden memcpy, and as
such it takes a size.
Or you could think of it as a hidden FCA load/store pair.