search for: vtbl

...WaitFor. Marcus Meissner (3): wined3d: Detect nouveau as NVIDIA. winex11.drv: Do not include XFORM.eDx and eDy into font hashing/caching. ntdll: Report a failed executable mmap on nonexec filesystems. Michael Stefaniuc (131): msimtf: Use an interface instance instead of a vtbl pointer. msdmo: Use an iface instead of a vtbl pointer in IEnumDMOImpl. atl: Use an iface instead of a vtbl pointer in the Registrar object. d3drm: Use an iface instead of a vtbl pointer in IDirect3DRMImpl. d3drm: Use an iface instead of a vtbl pointer in IDirect3DRMMeshBuil...

I took the output of clang, simplified it, and used it as a testbase. Essentially, there is one class with one virtual function; I create an instance and call the virtual method all in one function: ; The TestVirtual class vtbl @classvtbl.TestVirtual = constant %classvtbltype.TestVirtual { ; Pointers to the virtual methods for the TestVirtual class ... } ; ... define i32 @main() nounwind { ; create the instance %pinstance = alloca %class.TestVirtual ; %ppVtbl becomes a pointer to the instance's vtbl pointer. %pp...

...npt.c. mmdevapi: Standardize the COM usage in devenum.c. msctf/tests: Standardize the COM usage in inputprocessor.c. ole32/tests: Standardize the COM usage in clipboard.c. shlwapi/tests: Standardize the COM usage in ordinal.c. oleaut32/tests: Use an iface instead of an vtbl pointer in IRecordInfoImpl. msi: Use an iface instead of an vtbl pointer in IClassFactoryImpl. msi: Use an iface instead of a vtbl pointer in msi_custom_remote_impl. msi: Use an iface instead of a vtbl pointer in msi_remote_package_impl. msi: Use an iface instead of a vtbl p...

On Mon, Oct 11, 2010 at 12:30 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: >> 3. The front-end, recognizing that scribbling on an instance's vtbl >> pointer has undefined results, eliminated the loads of the vtbl >> pointer and replaced them with @classvtbl.TestVirtual.  This would >> allow devirtualization within a function at least, but (I think) would >> do less to allow analysis to spot devirtualization opportunit...

...gel (1): include: Remove extra semicolons after a macro that doesn't need them. David Hedberg (3): shell32: Fix test error on certain w2k8 setups. urlmon: Move protocol flags for wininet based protocols into a common header. urlmon: Add new on_error function to protocol vtbl. Eric Pouech (10): dbghelp: Fix ELF file computation on 64bit systems. winedbg: Don't print extra \n in print_basic. winedbg: When printing with default format an integer (in hex), keep printed value in sync with integer size. urlmon: Fixed traces on 64bit systems....

On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: > 3. The front-end, recognizing that scribbling on an instance's vtbl > pointer has undefined results, eliminated the loads of the vtbl > pointer and replaced them with @classvtbl.TestVirtual. This would > allow devirtualization within a function at least, but (I think) would > do less to allow analysis to spot devirtualization opportunities > across...

On Oct 11, 2010, at 10:43 AM, Kenneth Uildriks wrote: > On Mon, Oct 11, 2010 at 12:30 PM, John McCall <rjmccall at apple.com> wrote: >> On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: >>> 3. The front-end, recognizing that scribbling on an instance's vtbl >>> pointer has undefined results, eliminated the loads of the vtbl >>> pointer and replaced them with @classvtbl.TestVirtual. This would >>> allow devirtualization within a function at least, but (I think) would >>> do less to allow analysis to spot devirtualiz...

...e: > > On Oct 11, 2010, at 10:43 AM, Kenneth Uildriks wrote: > > On Mon, Oct 11, 2010 at 12:30 PM, John McCall <rjmccall at apple.com> wrote: > > On Oct 11, 2010, at 9:12 AM, Kenneth Uildriks wrote: > > 3. The front-end, recognizing that scribbling on an instance's vtbl > > pointer has undefined results, eliminated the loads of the vtbl > > pointer and replaced them with @classvtbl.TestVirtual.  This would > > allow devirtualization within a function at least, but (I think) would > > do less to allow analysis to spot devirtualization opport...

...Object,SC_PROXY_INTERFACE_VERSION); if ((lRc != SC_PROXY_OK) || (m_ProxyObject == 0)) { FreeLibrary (m_ProxyModule); m_ProxyModule = 0; return -2; } char* lParams = 0; lParams = strdup (""); OutputDebugString("vtbl->init getting called:"); // init R lRc = m_ProxyObject->vtbl->init (m_ProxyObject,lParams); OutputDebugString("done init."); free (lParams); if (lRc != SC_PROXY_OK) { m_ProxyObject->vtbl->release (m_ProxyObject);...

...ode): %ptr = call i8* @operator new(...) %a = bitcast %ptr to %A* call void @A::A(%a) call void @llvm.invariant.begin(%a) call void @llvm.invariant.end(%a) call void @A::~A(%a) %b = bitcast %a to %B* call void @B::B(%b) call void @llvm.invariant.begin(%b) call void @foo(%b) %b.vtbl = gep %a, 1 %vtbl = load %b.vtbl %fn.ptr = gep %vtbl, <offset> %fn = load %fn.ptr call %fn(%a) ... What's stopping us here from (incorrectly) replacing %vtbl with B's vtable pointer? John.

On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >> A better way for a front-end to declare that vtbl-ptr-hacking is not >> expected and not supported is for it to emit llvm.invariant.start and >> llvm.invariant.end calls for it. > > Some of us were talking about this apropos your earlier post. > @llvm.invariant.start/end aren't appropriate, because the memory *isn't* &...

...yone! My name is Žiga Osolin and I am one of administrators of baadengine project (www.baadengine.org). It is an open source, BSD-licenced, game engine. We are very interested in llvm to provide us runtime code generation (basically, wrappers to easily call scripts from C++ and vica-versa, via vtbl (we replace vtbl for scripted types)) and also to allow our VM to run on llvm. Our engine is intended to be OS neutral, so we also need windows version of llvm. I have checked the latest version of llvm and the VC7.1 projects don't seem to be up-to-date with you project (maybe I am mistaken...

On Wed, Oct 13, 2010 at 6:49 PM, John McCall <rjmccall at apple.com> wrote: > > On Oct 13, 2010, at 4:35 AM, Kenneth Uildriks wrote: > >> On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >>> Kenneth Uildriks wrote: >>>>> >>>>> You're right, I hadn't thought this through. The whole point of making

...ointer not based on it. Basically, I would like to be able to apply "noalias" to an instruction/virtual reg the same way that noalias is applied to function arguments. A few weeks ago when discussing devirtualization possibilities in C++, it turned out that while you can assume that the vtbl pointer is the same for every use of a given object pointer, you cannot assume that the vtbl pointer is the same for every pointer that MustAlias's that object pointer. This means that, without the ability to apply "noalias" to the result of placement-new, we cannot simply declare vt...

...rten Lankhorst (1): ole32: Handle alertable wait in CoWaitForMultipleHandles. Martin Petricek (1): gdiplus: Support for indexed formats in GdipBitmapSetPixel. Matteo Bruni (1): ntdll/tests: Add a FILE_APPEND_DATA test. Michael Stefaniuc (53): urlmon: Use ifaces instead of vtbl pointers in GopherProtocol. urlmon: Use ifaces instead of vtbl pointers in MimeFilter. urlmon: Use an iface instead of a vtbl pointer in MkProtocol. urlmon: Use an iface instead of a vtbl pointer in stgmed_buf_t. urlmon: Use ifaces instead of vtbl pointers in BindStatusCallb...

On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: > A better way for a front-end to declare that vtbl-ptr-hacking is not > expected and not supported is for it to emit llvm.invariant.start and > llvm.invariant.end calls for it. Some of us were talking about this apropos your earlier post. @llvm.invariant.start/end aren't appropriate, because the memory *isn't* invariant; the user is...

On Tue, Oct 12, 2010 at 7:00 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Mon, Oct 11, 2010 at 11:10 PM, John McCall <rjmccall at apple.com> wrote: >> On Oct 11, 2010, at 2:01 PM, Kenneth Uildriks wrote: >>> A better way for a front-end to declare that vtbl-ptr-hacking is not >>> expected and not supported is for it to emit llvm.invariant.start and >>> llvm.invariant.end calls for it. >> >> Some of us were talking about this apropos your earlier post. >> @llvm.invariant.start/end aren't appropriate, because the...

...that an object of a known type exists; we could experiment with adding an assumption from it any time that type is final. struct A { > virtual void foo() = 0; > }; > > struct B final : public A { > void foo(); > }; > > void entry(B *b) { > // emit assumptions about vtbl of 'b' here? > This case is tricky. We don't currently have a way of saying "assume that a load of %b would load %B.vtbl" without also saying "assume that %b is dereferenceable". We've seen other cases where that would be beneficial, so perhaps that's som...

...ed size, + const void *data, int data_size) +{ + struct nv04_resource *buf = nv04_resource(res); + struct pipe_transfer *pt; + struct pipe_box box; + unsigned elements, i; + + elements = size / data_size; + + u_box_1d(0, size, &box); + + uint8_t *map = buf->vtbl->transfer_map(pipe, res, 0, PIPE_TRANSFER_WRITE, + &box, &pt); + + for (i = 0; i < elements; ++i) + memcpy(&map[i*data_size], data, data_size); + + buf->vtbl->transfer_unmap(pipe, pt); +} + +static void +nvc0_clear_buffer(str...

...ase of 'final' classes I highlighted in initial e-mail by inserting these assumptions whenever a pointer/reference to a class of such a type came into scope? struct A { virtual void foo() = 0; }; struct B final : public A { void foo(); }; void entry(B *b) { // emit assumptions about vtbl of 'b' here? } Thanks again, Hal ----- Original Message ----- > From: "Piotr Padlewski" <prazek at google.com> > To: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, llvmdev at cs.uiuc.edu > Cc: "Richard Smith" <richard at...