by H. Peter Anvin

[permalink] [raw]

Subject: Re: [PATCH 74/74] lto, workaround: Mark do_futex noinline to prevent clobbering ebp

On 08/22/2012 07:29 PM, Andi Kleen wrote:
> How about just use register arguments for the first three arguments.
> This should work for the syscalls at least (may be too risky for all
> other asm entry points)

Well, it's just an effort to convert each one in turn...

> And for syscalls with more than three generate a stub that saves on the stack
> explicitely. This could be done using the new fancy SYSCALL definition macros
> (except that arch/x86 would need to start using them too in its own code)

I don't think there is any point. Just push the six potential arguments
to the stack and be done with it.

> Or is there some subtle reason with syscall restart and updated args
> that prevents it?
>
> Perhaps newer gcc can do regparm(X), X > 3 too, may be worth trying.

No, there is no such ABI defined.

> Don't have time to look into this currently though.

Always the problem.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

2012-08-23 15:13:10

by Jan Hubicka

[permalink] [raw]

Subject: Re: RFC: Link Time Optimization support for the kernel

> > 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 should make in long term life of developers easier, it is just not tool
how to get few extra % of performance.
There is a lot to do.
>
> BTW I should add LTO does more than just inlining:
> - Drop unused global functions and variables
> (so may cut down on ifdefs)
> - Detect type inconsistencies between files
> - Partial inlining (inline only parts of a function like a test
> at the beginning)
> - Detect pure and const functions without side effects that can be more
> aggressively optimized in the caller.
Also noreturn and nothorw are autodetected (the second is probably not big deal
for kernel, but it makes some C++ codebases a lot smaller by elliminating EH
and cleanps). We plan to add more in near future.
> - Detect global clobbers globally. Normally any global call has to
> assume all global variables could be changed. With LTO information some
> of them can be cached in registers over calls.
> - Detect read only variables and optimize them
> - Optimize arguments to global functions (drop unnecessary arguments,
> optimize input/output etc.)

At this moment this really happen s within compilation units only.
It is one of harder optimizations to get working over whole program,
we are slowly getting infrasrtucture to make this possible.

> - Replace indirect calls with direct calls, enabling other
> optimizations.
> - Do constant propagation and specialization for functions. So if a
> function is called commonly with a constant it can generate a special
> variant of this function optimized for that. This still needs more tuning (and
> currently the code size impact is on the largish side), but I hope
> to eventually have e.g. a special kmalloc optimized for GFP_KERNEL.
> It can also in principle inline callbacks.

Also profile propagation is done. When function is called only on cold paths, it becomes
cold.

Thanks for all the hard work on LTO kernel, Andi!
Honza
>
> -Andi
> --
> [email protected] -- Speaking for myself only.