[LLVMbugs] [Bug 6054] Virtual methods de-virtualization

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=6054


Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nlewycky at google.com,
                   |                            |nicholas at mxc.ca
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #4 from Nick Lewycky <nicholas at mxc.ca>  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.