[LLVMdev] alloc_size metadata

Nick Lewycky nicholas at mxc.ca
Tue Jun 5 23:07:01 PDT 2012


Nuno Lopes wrote:
>>> So here is a new proposal:
>>>
>>> !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* }
>>>
>>> alloc_size_fn and offset_fn are functions that return either i32/i64
>>> depending on the platform, and they must have the same number of
>>> arguments (not necessarily the same as the as allocation function).
>>> The parameters are given in the metadata as well.
>>> To accommodate the common case, offer_fn can be null, meaning it is a
>>> zero offset.
>>>
>>> The usage would be something like this:
>>>
>>> %r = call i8* @my_realloc(i32* %ptr, i32 %n), !alloc_size !0
>>> !0 = metadata !{ i32 (i32)* @size, null, i32 %n }
>>
>> suppose the size is %n+4.  Then in the function you have to compute
>>     %s = add i32 %n, 4
>> and then put %s in the metadata
>>     !0 = metadata !{ i32 (i32)* @size, null, i32 %s }
>> However then the only use of %s is in the metadata, so basically any
>> optimization pass will zap it, right?  So won't this only work if the
>> size etc calculation doesn't actually require any calculation, eg it
>> would work if you only pass function parameters and globals but that's
>> about it.  Am I missing something?
>
> Actually that's not what I had in mind.
> Metadata will take %n (and not %s) as the parameter for @size function, and
> then @size(%n) itself returns %n+4.

Just curious, what happens when @size is a declaration or a 
materializable function? Or what should happen?

   So no computations are supposed to be
> added to the caller of an allocation function. The metadata should only
> reference the parameters given to the allocation function. If the function
> is not inlined, then there is no risk of these parameters disappearing. If
> it is inlined, the probability is probably low, because you will most likely
> need the original parameters to compute the allocated size in the inlined
> function as well.

For as long as the optz'ns manage to RAUW the relevant Value's, the 
metadata will stay up to date.

Nick



More information about the llvm-dev mailing list