http://llvm.org/bugs/show_bug.cgi?id=6054
Nick Lewycky <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #4 from Nick Lewycky <[email protected]> 2010-01-16 11:29:24 --- Yup. I've been looking into on the stuff needed to make devirt happen for over a year now... let me give you a summary: The 'noalias' attribute on function return. We need to know that the pointer returned by malloc() or _Znwj (operator new) is a new pointer and not one to an existing object. Clang defaults to -fassume-sane-operator-new which marks global operator new with this attribute. The 'nocapture' attribute on pointer arguments. In C++, every method receives a pointer to 'this', and if that pointer is written elsewhere in memory then its type could be manipulated by functions that otherwise seem to have no connection to the object. With those two combined, we can (for example) receive FILE* from fopen, and pass it in to fread/fseek/fwrite then fclose, knowing that the pointer never aliases anything else at any time, not even an inttoptr instruction. LLVM's -functionattrs pass will calculate both 'noalias' and 'nocapture' and propagate them through the call graph. The 'available_externally' linkage is used to expose the contents of a global to the optimizers without causing it to be emitted anywhere. In our case, we use this for the vtables. So far, clang isn't emitting vtables in all the cases we need it to. The final piece of the puzzle is an interprocedural field-sensitive constant propagation pass. It would start at the point of allocation and follow writes of constants to the fields of the structure and propagate that value out to replace loads of that field. The goal is to replace the 'load the vtable from the object's vptr' operation of a virtual method call with the target vtable constant, and from there LLVM will optimize away the load of fptr and replace the indirect call with a direct one. *** This bug has been marked as a duplicate of bug 3100 *** -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
