search for: prazek

I get some failing tests from compiler-rt. FAIL: cfi :: cross-dso/stats.cpp (30831 of 30893) ******************** TEST 'cfi :: cross-dso/stats.cpp' FAILED ******************** Script: -- /usr/local/google/home/prazek/llvm-build-release/./bin/clang -fuse-ld=gold -flto -fsanitize=cfi -fwhole-program-vtables --driver-mode=g++ -fsanitize-cfi-cross-dso -fvisibility=default -DSHARED_LIB -fPIC -g -fsanitize-stats -shared -o /usr/local/google/home/prazek/llvm-build-release/projects/compiler-rt/test/cfi/Devirt/cross-dso...

There seem to be some recent regressions in clang/llvm. I see some test failing, and there is also this issue: https://llvm.org/bugs/show_bug.cgi?id=30466 Is anyone working on it? Piotr -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160920/ade5e8cd/attachment.html>

...eugeni.stepanov at gmail.com>, Fiona Glaser <escha at apple.com>, Guillaume Papin <guillaume.papin at epitech.eu>, Matt Arsenault < Matthew.Arsenault at amd.com>, Matthias Braun <matze at braunis.de>, Philip Reames <listmail at philipreames.com>, Piotr Padlewski <prazek at google.com>, Reid Kleckner <rnk at google.com>, Richard Trieu <rtrieu at google.com>, Sanjay Patel <spatel at rotateright.com>, Sanjoy Das <sanjoy at playingwithpointers.com>, Sean Silva <chisophugis at gmail.com>, Weiming Zhao <weimingz at codeaurora.org>...

...; > > escha at apple.com >, Guillaume Papin < guillaume.papin at epitech.eu >, > > Matt Arsenault < Matthew.Arsenault at amd.com >, Matthias Braun < > > matze at braunis.de >, Philip Reames < listmail at philipreames.com >, > > Piotr Padlewski < prazek at google.com >, Reid Kleckner < > > rnk at google.com >, Richard Trieu < rtrieu at google.com >, Sanjay Patel > > < spatel at rotateright.com >, Sanjoy Das < > > sanjoy at playingwithpointers.com >, Sean Silva < chisophugis at gmail.com > > &gt...

...aying "assume that %b is dereferenceable". We've seen other cases where that would be beneficial, so perhaps that's something we should consider adding. > } > > 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 metafoo.co.uk> > > Sent: Wednesday, July 22, 2015 4:55:43 PM > > Subject: [cfe-dev] Clang d...

On Thu, Jul 23, 2015 at 11:42 AM, Piotr Padlewski <prazek at google.com> wrote: > HI, > Yep, our proposal doesn't cover it, because this load ; icmp ; assume; > will land global initilizer function, and main will not see it. > At least if foo would be called multiple times, then we would only have > one load from vtable, but unfortu...

...ce 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 metafoo.co.uk> > Sent: Wednesday, July 22, 2015 4:55:43 PM > Subject: [cfe-dev] Clang devirtualization proposal...

...15 at 6:39 AM Hal Finkel < hfinkel at anl.gov > wrote: > > ----- Original Message ----- > > From: "Sanjoy Das" < sanjoy at playingwithpointers.com > > > To: "Reid Kleckner" < rnk at google.com > > > Cc: "Piotr Padlewski" < prazek at google.com >, " cfe-dev at cs.uiuc.edu > > Developers" < cfe-dev at cs.uiuc.edu >, "LLVM Developers > > Mailing List" < llvmdev at cs.uiuc.edu > > > Sent: Saturday, August 1, 2015 1:22:50 AM > > Subject: Re: [LLVMdev] [cfe-dev] Clang dev...

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

On Fri, Jul 31, 2015 at 6:18 PM, Reid Kleckner <rnk at google.com> wrote: > Consider this pseudo-IR and some possible transforms that I would expect to > be semantics preserving: > > void f(i32* readonly %a, i32* %b) { > llvm.assume(%a == %b) > store i32 42, i32* %b > } > ... > %p = alloca i32 > store i32 13, i32* %p > call f(i32* readonly %p,

And again... LLVM_BUILD_LLVM_DYLIB:BOOL=ON LLVM_LINK_LLVM_DYLIB:BOOL=ON This one is the good one... maybe. On Tue, Sep 6, 2016 at 11:35 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > That is because I mistyped it: > LLVM_ENABLE_LLVM_DYLIB:BOOL=ON > LLVM_LINK_LLVM_DYLIB:BOOL=ON > > On Tue, Sep 6, 2016 at 11:31 PM, Wink Saville <wink at saville.com>

> On Jul 23, 2016, at 1:53 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Jul 23, 2016 at 7:48 PM, Piotr Padlewski <prazek at google.com <mailto:prazek at google.com>> wrote: >> How big is your project? >> LTO eats RAM even faster than chrome. For example linking clang with LTO >> could take 16GB of ram. >> >> Have you tried using LTO on your project on that machine, or is it you...

...t;>> > >>> > ----- Original Message ----- >>> > > From: "Sanjoy Das" < sanjoy at playingwithpointers.com > >>> > > To: "Reid Kleckner" < rnk at google.com > >>> > > Cc: "Piotr Padlewski" < prazek at google.com >, " cfe-dev at cs.uiuc.edu >>> > > Developers" < cfe-dev at cs.uiuc.edu >, "LLVM Developers >>> > > Mailing List" < llvmdev at cs.uiuc.edu > >>> > > Sent: Saturday, August 1, 2015 1:22:50 AM >>>...

...gt; > > > > ----- Original Message ----- > > > > > From: "Sanjoy Das" < sanjoy at playingwithpointers.com > > > > > > To: "Reid Kleckner" < rnk at google.com > > > > > > Cc: "Piotr Padlewski" < prazek at google.com >, " > > > > cfe-dev at cs.uiuc.edu > > > > > Developers" < cfe-dev at cs.uiuc.edu >, "LLVM Developers > > > > > Mailing List" < llvmdev at cs.uiuc.edu > > > > > > Sent: Saturday, August 1,...

HI, Yep, our proposal doesn't cover it, because this load ; icmp ; assume; will land global initilizer function, and main will not see it. At least if foo would be called multiple times, then we would only have one load from vtable, but unfortunatelly we will not be able to inline, or make direct call to it with this approach. I think that this case is rare enough to solve it right now. Piotr

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > Quoting from the google doc: "If we don’t know definition of some > function, we assume that it will not call @llvm.invariant.group.barrier(). > " > This part really really bugs me. We generally try to assume minimal > knowledge of external functions (i.e. they can do

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 -

...ne time:strip(strip(%x)) => strip(%x) Examples with code snippetsHere are a couple of examples of emitted LLVM, assuming definition of type A and B as below. Note that no optimizations has been applied to this examples. If you want to see full code code check this snippet:https://gist.github.com/prazek/109c388d175a0114cf8a5e10787104ca <https://gist.github.com/prazek/109c388d175a0114cf8a5e10787104ca>and this one to see how it is optimized by current pipeline:https://gist.github.com/prazek/a0215c056821931136fef6f2b78f4962 <https://gist.github.com/prazek/a0215c056821931136fef6f2b78f4962>...

On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail at philipreames.com> wrote: > > I'm wondering if there's a problematic interaction with CSE here. > Consider this example is pseudo LLVM IR: > v1 = load i64, %p, !invariant.group !Type1 > ; I called destructor/placement new for the same type, but that optimized > entirely away > p2 =