Figuring out the type size for a malloc

[pwaller]

So, much like #52, I find myself generating some mallocs :) (cc @zegl @dannypsnl)

Immediately I run into the question: "how big should I make my malloc?"

Of course, I need to know the answer for arbitrary LLVM types, since I'm going to store LLVM values through that pointer.

So, this seems to me on the face of it a potentially difficult problem. Thoughts:

• It depends on your target.
• How many bytes does an i1 take?
• The size of structs especially is a non-trivial function of the data layout.
  • Alignment rules look complicated.

I note that there is an llvm.objectsize intrinsic, which can compute the size of an alloc'd object. So I can imagine using this in a creative way. Maybe that's the best way forward. I can imagine emitting a private synthetic function which just does an alloca, calls llvm.objectsize and returns the result. I imagine LLVM's optimizer will lower it to a constant int.

p.s. @zegl I saw you have a way of computing a type sizes, but it doesn't yet take into account some of the above issues, I guess?

Just wanted to see if anyone else has a creative solution, or if there is scope for llir/llvm or an llir package which knows about type sizes.

This isn't really an issue, more of a discussion - so please feel free to close this issue if it ever goes quiet. I figure this is a good enough place to do it :)

[mewmew]

Just wanted to see if anyone else has a creative solution, or if there is scope for llir/llvm or an llir package which knows about type sizes.

Computation of memory size may be dependent on decisions taken for a specific language regarding boxing, memory layout, padding, etc.

The aspects of those decisions that are captured by the data layout directive, I think we could add a util/helper library to compute it into something more usable than a string.

Something like, this perhaps?

// Package irutil provides utility functions for LLVM IR.
package irutil

// DataLayout describes the layout in memory of data structures for a specific
// target platform.
//
// ref: http://llvm.org/docs/LangRef.html#data-layout
type DataLayout struct {
   // what fields would this reasonably contain?
}

// ParseDataLayout parses the string representation of the given data layout.
func ParseDataLayout(layout string) DataLayout {
}

Open to other suggestions of course!

[pwaller]

Computation of memory size may be dependent on decisions taken for a specific language regarding boxing, memory layout, padding, etc.

Can you give a counter-example to what I write below?

My belief is that given some LLVM type definition and DataLayout, LLVM controls the size of the type, not the language. Of course, the language 'can have a say' in terms of how it chooses to build the type. But differences between boxing and not boxing actually means a different LLVM type.

[mewmew]

Can you give a counter-example to what I write below?

No. Reading what you wrote, I would have to agree. So, computing the size of a type based on e.g. a irutil.DataLayout would be reasonable to do.

package irutil

// SizeOf returns the size in bytes of the given type under the specified data layout.
func (layout DataLayout) SizeOf(t types.Type) int {
}

[mewmew]

Resolved by llir/irutil#2 (at least in part). See llir/irutil#2 (comment) for usage. It would be good to implement parsing and handling of data layout strings, building upon this API, and add such functionality to irutil.

[dannypsnl]

Resolved by llir/irutil#2 (at least in part). See llir/irutil#2 (comment) for usage. It would be good to implement parsing and handling of data layout strings, building upon this API, and add such functionality to irutil.

Maybe we create a new issue, and closing this one?

[mewmew]

Maybe we create a new issue, and closing this one?

Sounds good to me, feel free to create a new issue and close this one.