search for: hubicka

...but could you confirm that? I understand that neither can handle the very large Google applications, but that's probably not a near-term concern for a project like the one Charles is embarking on. Vikram, LLVM can handle Firefox size programs. Honza wrote two good articles about LTO. http://hubicka.blogspot.com/2014/04/linktime-optimization-in-gcc-1-brief.html http://hubicka.blogspot.com/2014/04/linktime-optimization-in-gcc-2-firefox.html Comparison with LLVM is described in the second article. It took about 40min to finish building Firefox with llvm using lto and -g. The following is a quot...

On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I’m totally willing to believe you that it is not possible to write the fastest ELF linker on earth (or in the universe) with a library based and reusable components approach. But clang is not the fastest C/C++ compiler available, and LLVM is not the fastest compiler framework either! I’m not

On Fri, Dec 12, 2014 at 1:59 PM, Diego Novillo <dnovillo at google.com> wrote: > On 12/12/14 15:56, Adve, Vikram Sadanand wrote: >> >> I've been asked how LTO in LLVM compares to equivalent capabilities >> in GCC. How do the two compare in terms of scalability? And >> robustness for large applications? > > > Neither GCC nor LLVM can handle our

...tion/-fno-semantic-interposition to Clang. > Default to -fno-semantic-interposition, but when -fsemantic-interposition > is used, use interposible linkage for all functions where external linkage > might otherwise have been used. > > Thoughts? > > Some useful links: > http://hubicka.blogspot.com/2015/04/GCC5-IPA-LTO-news.html (the section > on the -fno-semantic-interposition flag) > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01671.html > > On some issues with ELF protected-visibility symbols: > http://www.macieira.org/blog/2012/01/sorry-state-of- > dynamic...

...tion/-fno-semantic-interposition to Clang. > Default to -fno-semantic-interposition, but when -fsemantic-interposition > is used, use interposible linkage for all functions where external linkage > might otherwise have been used. > > Thoughts? > > Some useful links: > http://hubicka.blogspot.com/2015/04/GCC5-IPA-LTO-news.html (the section > on the -fno-semantic-interposition flag) > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01671.html > > On some issues with ELF protected-visibility symbols: > http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic- >...

...etc. 2. Add -fsemantic-interposition/-fno-semantic-interposition to Clang. Default to -fno-semantic-interposition, but when -fsemantic-interposition is used, use interposible linkage for all functions where external linkage might otherwise have been used. Thoughts? Some useful links: http://hubicka.blogspot.com/2015/04/GCC5-IPA-LTO-news.html (the section on the -fno-semantic-interposition flag) https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01671.html On some issues with ELF protected-visibility symbols: http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/ http:...

----- Original Message ----- > From: "James Y Knight" <jyknight at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 9:31:24 AM > Subject: Re: [llvm-dev] Possible soundness issue with

LLVM has a wonderful policy regarding broken commits: we revert to green. We ask that a test case be available within a reasonable time frame (preferably before, but some exceptions can be made), but otherwise we revert the offending patch, even if it contains nice features that people want, and keep the tree green. This is an awesome policy. I would like to suggest we adopt and follow the same

On Feb 26, 2016 8:50 PM, "Hal Finkel" <hfinkel at anl.gov> wrote: > *From: *"James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Sanjoy Das" <sanjoy at playingwithpointers.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Thursday, February 25, 2016 1:41:43 PM > *Subject: *Re: [llvm-dev]

...gt; -fsemantic-interposition is used, use interposible linkage for > > > all > > > functions where external linkage might otherwise have been used. > > > > > > Thoughts? > > > > > > Some useful links: > > > > > > http://hubicka.blogspot.com/2015/04/GCC5-IPA-LTO-news.html (the > > > section on the -fno-semantic-interposition flag) > > > > > > https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01671.html > > > > > > On some issues with ELF protected-visibility symbols: > >...

...I totally support considering compile time regression as bug. I'm glad you bring this topic. Also it is worth pointing at this recent thread: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096488.html And also this blog post comparing the evolution of clang and gcc on this aspect: http://hubicka.blogspot.nl/2016/03/building-libreoffice-with-gcc-6-and-lto.html I will repeat myself here, since we also noticed internally that compile time was slowly degrading with time. Bruno and Chris are working on some infrastructure and tooling to help tracking closely compile time regressions. We had t...

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

I have just benchmarked building trunk llvm and clang in Debug, Release and LTO modes (see the attached scrip for the cmake lines). The compilers used were clang 3.5, 3.6, 3.7, 3.8 and trunk. In all cases I used the system libgcc and libstdc++. For release builds there is a monotonic increase in each version. From 163 minutes with 3.5 to 212 minutes with trunk. For comparison, gcc 5.3.2 takes