search for: dead_stripping

Hi, I just came across a rather annoying behavior with llvm 3.9. Assuming the following samle code in test.ll: ; Lets have some global int x = 4 @x = global i32 10, align 4 ; and two strings "p = %d\n" for the prefix data, ; as well as "x = %d\n" to print the (global) x value. @.str = private unnamed_addr constant [8 x i8] c"x = %d\0A\00", align 1 @.str2 = private

On Mon, Mar 6, 2017 at 5:54 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Hi Peter, > > I’ve just experimented with this a bit: > > Say we would end up with the following assembly: > > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .globl _main.dsp > .alt_entry _main.dsp

That is in theory what omitting the .subsections_via_symbols directive is supposed to do, but in an experiment I ran a year or two ago I found that the Mach-O linker was still dead stripping on symbol boundaries with this directive omitted. In any case, a more precise approach has more recently (~a few months ago) become possible. There is a relatively new asm directive called .altentry that, as

I suspect that the format isn't important if you do that, but I wouldn't recommend it, at least because inlining (and other inter-procedural optimizations) are not expected to work correctly if you produce IR like that. Peter On Mon, Mar 6, 2017 at 6:44 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Peter, > > thanks again! Yes, we only need to refer to

Firstly, do you need "main.dsp" defined as an external symbol, or can all external references go via "main"? If the answer is the latter, that will make the solution simpler. If only the latter, you will need to make a change to LLVM here: http://llvm-cs.pcc.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile

> On Mar 6, 2017, at 7:56 PM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh, that's great that it's possible to implement properly, now. Does it actually work for > > It'd be cool if LLVM hooked up its generic section handling support to this feature now, so that the only global symbols that *didn't* get marked as .alt_entry were

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

...ce. Is it because the globals added to compiler used is ignored by the optimizer so they cannot be internalized and they cannot be optimized away? This works well for the case I am looking at because c++ VTable can't really be optimized and for darwin platforms because we can rely on ld64 to do dead_stripping if needed. 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. Well,this doesn't really preserve the link semantics, but neither does promoting linkonce_odr to weak_odr. The global will still end up in the symbol table but at least it isn't external so it doesn't come w...

...e globals added to compiler used is > ignored by the optimizer so they cannot be internalized and they cannot be > optimized away? This works well for the case I am looking at because c++ > VTable can't really be optimized and for darwin platforms because we can > rely on ld64 to do dead_stripping if needed. > > 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. > Well,this doesn't really preserve the link semantics, but neither does > promoting linkonce_odr to weak_odr. The global will still end up in the > symbol table but at least it isn't external s...

...to compiler used is >> ignored by the optimizer so they cannot be internalized and they cannot be >> optimized away? This works well for the case I am looking at because c++ >> VTable can't really be optimized and for darwin platforms because we can >> rely on ld64 to do dead_stripping if needed. >> >> 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. >> Well,this doesn't really preserve the link semantics, but neither does >> promoting linkonce_odr to weak_odr. The global will still end up in the >> symbol table but at least it...

...e globals added to compiler used is > ignored by the optimizer so they cannot be internalized and they cannot be > optimized away? This works well for the case I am looking at because c++ > VTable can't really be optimized and for darwin platforms because we can > rely on ld64 to do dead_stripping if needed. > > 2. Add visibility hidden when promote linkonce_odr + unnamed_addr. > Well,this doesn't really preserve the link semantics, but neither does > promoting linkonce_odr to weak_odr. The global will still end up in the > symbol table but at least it isn't external s...