Re: Livepatch vs LTO

2019-04-26 Thread Jan Hubicka
> [ adding CCs ] > > On Thu, 25 Apr 2019, Josh Poimboeuf wrote: > > > Hi all, > > > > On IRC, Peter expressed some concern about -flive-patching, specifically > > that the flag isn't compatible with LTO. > > > > The upstream kernel currently doesn't support LTO, but Android is using > > it with

Re: [PATCH] x86: Turn off GCC branch probability heuristics

2015-04-12 Thread Jan Hubicka
Hello, for me as GCC developer, this is definitely an intersting observation. Let me briefly explain what happen here. -fguess-branch-probability does a lot more than just BB reordering. The way GCC works is that it first guesses probability of every branch and then uses the probabilities to esti

Re: [GIT] kbuild/lto changes for 3.15-rc1

2014-04-08 Thread Jan Hubicka
> Hi Linus, > > > So right now, I see several reasons not to merge it ("It's so > > experimental that we don't even want to encourage people to test it" > > I don't want them to enable it during allyesconfig because they > might need more than 4GB of RAM to build it (especially with gcc > 4.8, 4

Re: RFC: Link Time Optimization support for the kernel

2012-08-23 Thread Jan Hubicka
> > If data structures could be encapsulated/internalized to > > subsystems and only global functions are exposed to other > > subsystems [which are then LTO optimized] then our include > > file dependencies could become a *lot* simpler. > > Yes, long term we could have these benefits. Yes, LTO

Re: [discuss] [PATCH] x86-64: memset optimization

2007-08-20 Thread Jan Hubicka
> > > The problem is with the optimization flags: passing -Os causes the > compiler > > > to be stupid and not inline any memset/memcpy functions. > > > > you get what you ask for.. if you don't want that then don't ask for > > it ;) > > Well, the compiler is really being dumb about -Os and

Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints

2007-07-23 Thread Jan Hubicka
> > > Whoa, thanks for explaining that to me -- I didn't know, obviously. I had > > just written a test program that used "Ir" with an automatic variable > > defined in the inline function (as is the case with these bitops) and > > observed that even when I gave > 32 values, it would still work --

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

2005-04-01 Thread Jan Hubicka
> On Wednesday 30 March 2005 05:27, Gerold Jury wrote: > > > > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote: > > >> > /* > > >> > * This looks horribly ugly, but the compiler can optimize it totally, > > >> > * as the count is constant. > > >> > */ > > >> > static inline vo