RFC: alloca -- specify rounding factor for allocation (and more)

Hi

sorta piggybacking on the other thread. I am looking for some feedback on how to implement the following idea in llvm.

The really short version of the idea is this:

* I want to alloca a field (record/struct), so that its size is an even multiple of 64 bytes. [^1]
* This allocaed field will be exclusively used as an argument to functions
* llvm should be aware of the extra bytes and should be able to use them in subsequent arguments to function calls (e.g. tail calls)

... Why do I need this ? http://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html

AFAIK AllocaInst can do address alignment but not size alignment. I wonder if that would be an "OK" addition to llvm, if one could specify a rounding also ?

Then I would need a way to signal to llvm that this is a special field, so that it may reuse all the space. Would I mark that passed in struct with a new __attribute or some such ?

Finally I would need an optimization pass (?), that would check that the alloca is big enough to hold the values and that the values aren't needed afterwards anymore and then reuse the alloca.

It would be good to know, by people more well versed in llvm (pretty much anyone on this list :), if this is basically the right approach and how much llvm maybe can already do.

Ciao
    Nat!

P.S. Here is some code, that shows what is technically desired:

# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.

allocas support alignment, and I believe the backend will sort stack objects by alignment to try to pack data into the padding. If I’m wrong, this is probably a reasonable feature request. That said, 64-byte alignment is larger than the default 16-byte stack alignment available on most platforms, so you’ll end up using a more expensive prologue. I’d recommend reducing the alignment back to 16.

Thanks a lot for the response.

Reid Kleckner schrieb:

allocas support alignment, and I believe the backend will sort stack
objects by alignment to try to pack data into the padding. If I'm wrong,
this is probably a reasonable feature request. That said, 64-byte
alignment is larger than the default 16-byte stack alignment available
on most platforms, so you'll end up using a more expensive prologue. I'd
recommend reducing the alignment back to 16.

I don't really need alignment, I need size :slight_smile: I can see how aligment could trick two allocas into one being of a proper size, but that wouldn't really work for me.

But I am pretty sure now, I will do the rounding from clang with a union. It's just easier. I will round to 5 * sizeof( void *) which should give sufficient room for the interesting cases, but not waste too much stack space.