<br><br><div class="gmail_quote">On Thu, May 24, 2012 at 7:43 PM, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu" target="_blank">criswell@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 5/24/12 3:51 AM, Duncan Sands wrote:<br>
> Hi Nuno,<br>
><br>
>> I'm implementing the alloc_size function attribute in clang.<br>
> does anyone actually use this attribute? And if they do, can it really buy<br>
> them anything? How about "implementing" it by ignoring it!<br>
<br>
</div>Tools like ASan and SAFECode *could* use this attribute</blockquote><div><br></div><div>A case where this may be useful for asan: </div><div> size_t n, m; ...</div><div> int *x = new int [n]; ...</div><div> x[m] // here we can check "m < n" instead of a more expensive shadow memory lookup. </div>
<div>For asan such optimization is possible only if 'x' does not escape the current function before the use, </div><div>otherwise we may lose a use-after-free. </div><div><br></div><div>I don't know whether such optimization will fire often enough to pay the price for the added complexity of the implementation.</div>
<div>It would be interesting to see statistics on some huge app.</div><div><br></div><div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
to determine the<br>
size of memory objects created by allocators. This is needed for things<br>
like SAFECode's fastcheck optimization (which replaces expensive checks<br>
that need to lookup object bounds with a simpler check that has the<br>
object bounds passed in as arguments) as well as its instrumentation to<br>
register heap object bounds with the SAFECode run-time.<br>
<br>
Currently, SAFECode has a pass which just recognizes certain functions<br>
as allocators and knows how to interpret the arguments to find the<br>
size. If we want SAFECode to work with another allocator (like a<br>
program's custom allocator, the Objective-C allocator, the Boehm garbage<br>
collector, etc), then that pass needs to be modified to recognize it.<br>
Having to update this pass for every allocator name and type is one of<br>
the few reasons why SAFECode only works with C/C++ and not just any old<br>
language that is compiled down to LLVM IR.<br>
<br>
Nuno's proposed feature would allow programmers to communicate the<br>
relevant information about allocators to tools like SAFECode and ASan.<br>
I think it might also make some of the optimizations in LLVM that<br>
require knowing about allocators work on non-C/C++ code.<br>
<br>
So, no, I don't think anything's using it now, but it looks like<br>
something very useful to add, and I think some of those useful things<br>
are already a part of core LLVM.<br>
<br>
-- John T.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Ciao, Duncan.<br>
><br>
> This<br>
>> attribute exists in gcc since version 4.3.<br>
>> The attribute specifies that a function returns a buffer with the size<br>
>> given by the multiplication of the specified arguments. I would like<br>
>> to add new metadata to pass this information to LLVM IR.<br>
>><br>
>> For example, take the following C code:<br>
>><br>
>> void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)));<br>
>><br>
>> void* fn() {<br>
>> return my_calloc(1, 3);<br>
>> }<br>
>><br>
>><br>
>> which would get translated to:<br>
>><br>
>><br>
>> define i8* @fn() {<br>
>> entry:<br>
>> %call = call i8* @my_calloc(i32 1, i32 3), !alloc_size !0<br>
>> ret i8* %call<br>
>> }<br>
>><br>
>> declare i8* @my_calloc(i32, i32)<br>
>><br>
>> !0 = metadata !{i32 0, i32 1}<br>
>><br>
>><br>
>> The downsize is that the metadata is added to all call sites, since<br>
>> it's not possible to attach metadata to function declarations.<br>
>><br>
>> Any comment, suggestion, etc?<br>
>><br>
>> Thanks,<br>
>> Nuno<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>