search for: fwhole

Hi all, I'd like to make a proposal to implement the new vtable ABI described in PR26723, which I'll call the relative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing implementation of whole-program vcall optimization allows external code to call into translation units compiled with -fwhole-program-vtables, but does not allow e...

...s.llvm.org> wrote: > Hi all, > > I'd like to make a proposal to implement the new vtable ABI described in > PR26723, which I'll call the relative ABI. That bug gives more details and > justification for that ABI. > > The user interface for the new ABI would be that -fwhole-program-vtables > would take an optional value indicating which aspects of the program have > whole-program scope. For example, the existing implementation of > whole-program > vcall optimization allows external code to call into translation units > compiled with -fwhole-program-vtab...

...b){ return a*b; } int main(void){ return 0; } While mult is never called it still is not removed. I just can't seem to get opt to understand it's seeing the whole program so it can remove this globally accessible function. What am I missing? Seems related to the missing -fwhole-program flag in clang. Perhaps this is not even possible? If I can't get any answers here I may repost that specific question since I didn't list [opt] in the original question subject. Thanks, Ed On Fri, Jul 17, 2015 at 1:15 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > ed...

...in llvm compares to the results being seen in current gcc trunk with their LTO... http://gcc.gnu.org/ml/gcc/2009-10/msg00155.html It would appear that the gcc LTO implementation is finally showing results (although with a lot of wrong code results). I assume we really don't have a functional -fwhole-program in llvm-gcc-4.2 but do we have one in clang? Jack

...ink time, and also to allow bitcode objects to be shared between links of targets with differing valid LTO visibility. This utilizes the !vcall_visibility metadata added for Dead Virtual Function Elimination. The summary of changes required are (these are described in more detail later): 1) When -fwhole-program-vtables is specified, always insert type test assumes for virtual calls, and additionally add !vcall_visibility metadata to vtable definitions (which will be summarized in the ThinLTO index). 2) At LTO link time, apply hidden LTO visibility to vtable definition vcall_visibility metadata (o...

Hi All , We are in process of exploring the LTO and found that internalize pass is the replacement for whole program optimisation (-fwhole-program in gcc) in clang and in the below case define i32 @test() #0 { entry: ret i32 0 } define i32 @main() #0 { entry: %retval = alloca i32, align 4 store i32 0, i32* %retval, align 4 %call = call i32 @test() ret i32 %call } *** IR Dump After Internalize Global Symbols *...

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/Output/ stats.cpp.tmp.so /usr/local/google/home/prazek/llvm/projects/comp...

Mike Stump wrote: > On Mar 24, 2009, at 10:22 AM, Luke Dalessandro wrote: > >> I guess that alias analysis doesn't always "trust" casts, where if I >> manually >> pushed back I would be assuming that the casts are correct? > > Once all the pushing is in, one should be able to discover that the > casts all convert to the same type, and remove

...org> wrote: > > > > On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program in gcc) in clang and in the below case > > define i32 @test() #0 { > > entry: > > ret i32 0 > > } > > > define i32 @main() #0 { > > entry: > > %retval = alloca i32, align 4 > > store i32 0, i32* %retval, align 4 > >...

...to 10x their fully optimized gcc equivalent (1.5k vs 16k). This is for a bare metal ARM based system so this is significant. We're using lld for linking and the following dead code elimination techniques seem to be dead ends: 1) whole program optimization on our most egregious space waster (-fwhole-program not supported by clang) 2) link time optimization (looks like this is only supported by lld for the COFF path not the ELF path) 3) using a linker plugin like gold (-fuse-linker-plugin doesn't seem to be supported by clang) We have control over the whole codebase and could essentially c...

...to emphasise that these numbers are from a regular LTO build without CFI, and that we expect to see better performance from a general implementation that targets all virtual functions. ==User interface== To instruct the compiler to assume that all type hierarchies are closed, a user can pass the -fwhole-program-vtables flag. The -fwhole-program-vtables flag requires the -flto flag to also be specified. Of course, there may be some type hierarchies that are not entirely closed, but the underlying assumption is that most hierarchies will not be. To support open hierarchies the user can also specify...

On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program in gcc) in clang and in the below case > > define i32 @test() #0 { > > entry: > > ret i32 0 > > } > > > define i32 @main() #0 { > > entry: > > %retval = alloca i32, align 4 > > store i32 0, i32* %retval, align 4 > > %call =...

...gt;> >> On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi All , >> >> We are in process of exploring the LTO and found that internalize >> pass is the replacement for whole program optimisation >> (-fwhole-program in gcc) in clang and in the below case >> >> define i32 @test() #0 { >> >> entry: >> >> ret i32 0 >> >> } >> >> >> define i32 @main() #0 { >> >> entry: >> >> %retval = alloca i32, align 4...

...an stock dragonegg but 12% faster than stock gcc 4.5.4. The most interesting executable size difference is gas_dyn which fastest with optzns but 11x larger in size with stock gcc 4.5.4 compared to either stock dragonegg or dragonegg with optzns. This is likely much improved in gcc 4.6 with the new -fwhole-file default. On Thu, Jun 09, 2011 at 09:51:51AM +0200, Duncan Sands wrote: > Hi Jack, thanks for these numbers. Can you also please measure compile times? > I'm thinking of enabling gcc optimizations by default, but I don't want to > increase compile times, which means choosing...

...Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Hi All , >>> >>> We are in process of exploring the LTO and found that internalize >>> pass is the replacement for whole program optimisation >>> (-fwhole-program in gcc) in clang and in the below case >>> >>> define i32 @test() #0 { >>> >>> entry: >>> >>> ret i32 0 >>> >>> } >>> >>> >>> define i32 @main() #0 { >>> >>> entry:...

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>

...that are used to implement CFI (see https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) so that they are also used whenever a branch funnel needs to be created. The compiler will only use branch funnels when both the retpoline mitigation (-mretpoline) and whole-program devirtualization (-fwhole-program-vtables) features are enabled (the former is on the assumption that in general a regular indirect call will be less expensive than a branch funnel, and the latter provides the necessary guarantee that the type hierarchy is closed). Even when retpolines are enabled, there is still a cost ass...

...ut 12% faster than stock gcc 4.5.4. The most interesting executable > size difference is gas_dyn which fastest with optzns but 11x larger > in size with stock gcc 4.5.4 compared to either stock dragonegg or > dragonegg with optzns. This is likely much improved in gcc 4.6 with > the new -fwhole-file default. > > On Thu, Jun 09, 2011 at 09:51:51AM +0200, Duncan Sands wrote: >> Hi Jack, thanks for these numbers. Can you also please measure compile times? >> I'm thinking of enabling gcc optimizations by default, but I don't want to >> increase compile times,...

...s 0. The only problem is that you could have another translation unit, and it could be in C++, and it could have a global object with a constructor that runs, and that constructor might set the value of x to 1. So, inferring the value is 0 isn't possible in that case. Now, if you do -fwhole-program and/or tell the optimizer the only export is main, it might have a chance at doing that you want.

...FI > (see https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html) so that > they are also used whenever a branch funnel needs to be created. > > The compiler will only use branch funnels when both the retpoline > mitigation (-mretpoline) and whole-program devirtualization > (-fwhole-program-vtables) features are enabled (the former is on the > assumption that in general a regular indirect call will be less expensive > than a branch funnel, and the latter provides the necessary guarantee that > the type hierarchy is closed). Even when retpolines are enabled, there is &...