similar to: [LLVMdev] Missed devirtualization opportunities

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

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

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

On Mon, Oct 11, 2010 at 3:55 PM, John McCall <rjmccall at apple.com> wrote: > > 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 > >

Full_Name: Venkatesh Mysore Version: R-1.7.0 OS: WindowsXP Submission from: (NULL) (216.165.110.10) While accessing Rproxy.dll repeatedly (using the code from the (D)COM example in the R website) causes a failure in the 24th iteration. R-1.6.2 does NOT give this error. This seems to be a memory management error, that might be linked to the huge leakage difference between R-1.7.0 and R-1.6.2

Hello, everyone! 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

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

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

On Sat, Jul 25, 2015 at 12:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Piotr, > > Thanks for posting this! First, a question. When you say, regarding i8* > @llvm.invariant.group.barrier(i8*): > > "Required to handle destructors, placement new and std::launder. Call of > this function will be put on the end of each of this functions" > > I

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

v2: - change patch name to "nvc0: implement clear_buffer" - rename nvc0_clear_buffer_rgb32 -> nvc0_clear_buffer_cpu and make it work for all formats - remove superfluous fenciing in nvc0_clear_buffer_cpu - coding style fixes v3: - more coding style fixes - nvc0_clear_buffer() - don't mark the framebuffer dirty for if we don't touch the GPU Signed-off-by: Tobias

v2: change patch according to Ilia Mirkins review --- src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 151 ++++++++++++++++++++++++ 1 file changed, 151 insertions(+) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c index 6b7c30c..242924a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c +++

Hi Piotr, Thanks for posting this! First, a question. When you say, regarding i8* @llvm.invariant.group.barrier(i8*): "Required to handle destructors, placement new and std::launder. Call of this function will be put on the end of each of this functions" I completely understand placement new and std::launder. I don't understand destructors, could you explain? Also, am I correct

John McCall 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

The Wine development release 1.3.9 is now available. What's new in this release (see below for details): - Beginnings of support for ActiveX in built-in browser. - Icons on Internet shortcut menu entries. - Standardization of code implementing COM interfaces. - New scheme for auto-generated DLL registrations. - OpenCL library wrapper. - Translation updates. - Various bug fixes.

On Oct 11, 2010, at 10:06 PM, Nick Lewycky wrote: > John McCall 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

The Wine development release 1.3.10 is now available. What's new in this release (see below for details): - Support for notification balloons in system tray. - Obsolete AudioIO sound driver removed. - More work on ActiveX support. - Various MSI fixes. - Preloader now used for 64-bit too. - Translation updates. - Various bug fixes. The source is available from the following

The Wine development release 1.3.11 is now available. What's new in this release (see below for details): - PO files now used for translations. - Various JavaScript improvements. - Some fixes to the Wine debugger. - Translation updates. - Various bug fixes. The source is available from the following locations:

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

On Oct 13, 2010, at 5:09 PM, Kenneth Uildriks wrote: > But I believe the language does allow "undefined behavior" if there's > a use of pT when the pointed-to object isn't actually of type T. It's > an invalid use in that case, right? Yes, but not for an arbitrary pointer which aliases pT. That's why it's a problem that llm.invariant is specified in terms