search for: launder

...that accessing class field, or comparing pointers to dynamic objects would require a call to a new intrinsic - i8* llvm.strip.invariant.group(i8* ) to firstly get pointer without information about dynamic type. Creation (or reloading) of fat pointer would be done by call to new intrinsic - i8* llvm.launder.invariant.group(i8*) that replaces llvm.invariant.group.barrier.The pointer comparison will now not be an issue, because the optimizer will not be able to replace the operand of a virtual pointer load with another pointer:%vtable_a = load i8* %a, !invariant.group !{};;;; %a == %b%addr_a = call i8*...

...that accessing class field, or comparing pointers to dynamic objects would require a call to a new intrinsic - i8* llvm.strip.invariant.group(i8* ) to firstly get pointer without information about dynamic type. Creation (or reloading) of fat pointer would be done by call to new intrinsic - i8* llvm.launder.invariant.group(i8*) that replaces llvm.invariant.group.barrier. > > The pointer comparison will now not be an issue, because the optimizer will not be able to replace the operand of a virtual pointer load with another pointer: > > > %vtable_a = load i8* %a, !invariant.group !{} &...

...field, or comparing pointers to dynamic objects would require a call > to a new intrinsic - i8* llvm.strip.invariant.group(i8* ) to firstly get > pointer without information about dynamic type. Creation (or reloading) of > fat pointer would be done by call to new intrinsic - i8* > llvm.launder.invariant.group(i8*) that replaces > llvm.invariant.group.barrier.The pointer comparison will now not be an > issue, because the optimizer will not be able to replace the operand of a > virtual pointer load with another pointer:%vtable_a = load i8* %a, > !invariant.group !{};;;; %a == %...

...nsics, at least to achieve a clean implementation thereof. Our primary example is devirtualization[RFC: Devirtualization v2 <https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit>], which requires that the LLVM IR be annotated with certain intrinsic calls, viz. launder.invariant.group and strip.invariant.group, in certain places, e.g. when the dynamic type of an object changes. This currently makes it impossible to merge IR created with this kind of optimization in mind and without it, as this can lead to miscompilation when the optimizer relies on the lack of i...

...2018-03-28 23:23 GMT+02:00 John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>>: >> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> Note that adding calls to strip and launder related to pointer comparisons and integer<->pointer conversions will not cause any semantic information to be lost: if any piece of information could be inferred by the optimiser about some collection of variables (e.g. that two pointers are equal) can be inferred now about their stripped ve...

...ski <piotr.padlewski at gmail.com> > wrote: > 2018-03-28 23:23 GMT+02:00 John McCall <rjmccall at apple.com>: >> >> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> *Note that adding calls to strip and launder related to pointer >> comparisons and integer<->pointer conversions will not cause any semantic >> information to be lost: if any piece of information could be inferred by >> the optimiser about some collection of variables (e.g. that two pointers >> are equal) can be...

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 completely understand placement new and std::launder. I don't understand > destructors, could you explain? > When a derived class destructor invokes a base class destructor, the dynamic type of...

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 in saying that we could handle the case of 'final' classes I highlighted in initi...

...28 23:23 GMT+02:00 John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>>: >>> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >>> Note that adding calls to strip and launder related to pointer comparisons and integer<->pointer conversions will not cause any semantic information to be lost: if any piece of information could be inferred by the optimiser about some collection of variables (e.g. that two pointers are equal) can be inferred now about their stripped ve...

...actually > doesn't > transition or whether it was compiled without the transitions being > explicitly > marked. There's no way to extend the TBAA idea to make that work. > The other reason why similar scheme doesn't work for !invariant.group is that we rely on a calls to launder/strip being present for some constructs to preserve information about invartianess of an object (like in the example from RFC). > On 12/4/18 11:24 AM, John McCall via llvm-dev wrote: > > Note that IPO is generally permitted to partially inline or outline code, > and so good-faith optim...

...tarball. Could some one tell me where I can find this or am I supposed to make my own? If so is there and example that I can follow? Thanks in advance for your help Drew -- In line with our policy, this message has been scanned for viruses and dangerous content by Technology Tiger's Mail Launder system <www.mail-launder.com> Our email policy can be found at www.technologytiger.net/policy Technology Tiger Limited is registered in Scotland with registration number: 310997 Registered Office 55-57 West High Street Inverurie AB51 3QQ

Hurray! Hopefully, he'll get put away for a while. Charged with SPAMming, money laundering, fraud, etc. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} Oppose globalization and One World Governments like the UN. This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for...

...fault configuration when accessing a remote machine using `ssh root@remote virt-tool ...' I think we should drop all references to XDG_RUNTIME_DIR (as I noted before, I don't have a high regard for freedesktop pseudo-standards, which I believe are just a way for some people to "policy launder" junk into Linux). The attached patch does that. Note the get-sockdir function now returns the hard-coded value "/tmp", which may or may not be a good idea. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualizat...

...phis, selects, etc. I’ll call this kind of uses "aliases", for the lack of better word. * Capturing. The "aliases" are tricky. CT users often need to know about these. For example, rL331587<https://reviews.llvm.org/rL331587> taught CT the "alias" semantic of launder.invariant.group calls. Because BasicAA was not aware of this change, it lead to incorrect AA results. "BasicAA still considered every call instruction as a possible escape source and hence concluded that the result of a launder_invariant_group call cannot alias any local non-escaping value.&qu...

Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX

...eems like you're assuming that only the > invariant.group > metadata needs to be parameterized with a supported_optimization. > Should you > also decorate all the other structures used as part of this > optimization, e.g. > the calls to llvm.strip.invariant.group and > llvm.launder.invariant.group? > This would also allow these intrinsics to be more explicit about exactly > which > family of invariant.group metadata they're supposed to be > laundering/stripping, > and correspondingly it would allow LLVM to remove these intrinsics when > it > strips in...

Hi folks, this summer I will work with Richard Smith on clang devirtualization. Check out our proposal: https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing And modified LangRef http://reviews.llvm.org/D11399 You can also check out previous disscussion that was started before our proposal was ready -

...to the limitations coming from other parties involved (libvirt in this case). > I think we should drop all references to XDG_RUNTIME_DIR (as I noted > before, I don't have a high regard for freedesktop pseudo-standards, > which I believe are just a way for some people to "policy launder" > junk into Linux). There isn't any needed to scrap everything at the first issue, there actually is a way to make this work better. Also, not having high regards does not automatically mean that things are obnoxious, not that there isn't any middle ground possible. > The att...

The attached patch is needed to make flac build on Solaris. Can some/all of these changes go upstream? Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: flac-01-forte.diff Type: text/x-patch Size: 3186 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20070124/c752fe5e/flac-01-forte-0001.bin

...lace to submit this :~) Yes. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- `If you want a vision of the future, it is a wireless broadband network feeding requests for foreign money-laundering assistance into a human temporal lobe, forever. With banner ads.' -- John M. Ford