Hi Nuno,> 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? Ciao, Duncan.
>> 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. 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. Nuno
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
Quoting Nuno Lopes <nunoplopes at sapo.pt>:>>> 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. 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. > > NunoOk, so please find in attach a patch that adds the alloc attribute. Other things to follow are the discussion on a new linkage type, and refactoring of the memory built-ins analysis, clang support, etc. Nuno -------------- next part -------------- A non-text attachment was scrubbed... Name: alloc_metadata.diff Type: text/x-patch Size: 8312 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120606/36b4f750/attachment.bin>