On Mon, 04 Jun 2012 18:37:31 +0100 Nuno Lopes <nunoplopes at sapo.pt> wrote:> Hi, > > 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 } > > Even if my_realloc() gets inlined later, the metadata can still be > applied to the returned value (since it is not really specific to a > call site). Of course some parameters of the allocation function may > be deleted if the function gets inlined (i.e., nulled in the > metadata), but I don't think we can workaround that problem. This is > a best-effort approach, anyway. > > > To avoid these functions being removed, I propose a new linkage > type. Something like internal_metadata (or hopefully a better name). > This linkage would mean that a function can only be removed in > codegen, and if it has no users. The difference to internal linkage, > is that internal functions with no users can be deleted at any time.Is it possible to determine which functions are referenced in metadata even though the metadata is not listed as a user? It seems like we could do this without defining another linkage class.> > So, what do you think about this new proposal? I guess it addresses > all issues raised so far.I think this is good. -Hal> > Thanks, > Nuno > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
>> Hi, >> >> 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 } >> >> Even if my_realloc() gets inlined later, the metadata can still be >> applied to the returned value (since it is not really specific to a >> call site). Of course some parameters of the allocation function may >> be deleted if the function gets inlined (i.e., nulled in the >> metadata), but I don't think we can workaround that problem. This is >> a best-effort approach, anyway. >> >> >> To avoid these functions being removed, I propose a new linkage >> type. Something like internal_metadata (or hopefully a better name). >> This linkage would mean that a function can only be removed in >> codegen, and if it has no users. The difference to internal linkage, >> is that internal functions with no users can be deleted at any time. > > Is it possible to determine which functions are referenced in metadata > even though the metadata is not listed as a user? It seems like we > could do this without defining another linkage class.Right now, no. We would need a map from Function* to metadata, since we don't really want to scan the whole metadata every time we want to delete a function. So, I don't know.. I'm pretty agnostic to either solution. Nuno
On Tue, 5 Jun 2012 15:57:25 +0100 "Nuno Lopes" <nunoplopes at sapo.pt> wrote:> >> Hi, > >> > >> 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 } > >> > >> Even if my_realloc() gets inlined later, the metadata can still be > >> applied to the returned value (since it is not really specific to a > >> call site). Of course some parameters of the allocation function > >> may be deleted if the function gets inlined (i.e., nulled in the > >> metadata), but I don't think we can workaround that problem. This > >> is a best-effort approach, anyway. > >> > >> > >> To avoid these functions being removed, I propose a new linkage > >> type. Something like internal_metadata (or hopefully a better > >> name). This linkage would mean that a function can only be removed > >> in codegen, and if it has no users. The difference to internal > >> linkage, is that internal functions with no users can be deleted > >> at any time. > > > > Is it possible to determine which functions are referenced in > > metadata even though the metadata is not listed as a user? It seems > > like we could do this without defining another linkage class. > > Right now, no. > We would need a map from Function* to metadata, since we don't really > want to scan the whole metadata every time we want to delete a > function. So, I don't know.. I'm pretty agnostic to either solution.Fair enough. I'd prefer a more descriptive name if we use a linkage class; how about metadata_referenced or referenced_by_metadata or used_by_metadata, etc. (maybe also with the internal_ prefix as well)? If there is an efficient way to maintain the map, I think that would be better. Thanks again, Hal> > Nuno >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory