[lkml]   [2018]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROPOSAL: Extend inline asm syntax with size spec
On October 7, 2018 6:09:30 PM GMT+02:00, Nadav Amit <> wrote:
>at 2:18 AM, Borislav Petkov <> wrote:
>> Hi people,
>> this is an attempt to see whether gcc's inline asm heuristic when
>> estimating inline asm statements' cost for better inlining can be
>> improved.
>> AFAIU, the problematic arises when one ends up using a lot of inline
>> asm statements in the kernel but due to the inline asm cost
>> heuristic which counts lines, I think, for example like in this here
>> macro:
>> the resulting code ends up not inlining the functions themselves
>> use this macro. I.e., you see a CALL <function> instead of its body
>> getting inlined directly.
>> Even though it should be because the actual instructions are only a
>> couple in most cases and all those other directives end up in another
>> section anyway.
>> The issue is explained below in the forwarded mail in a larger detail
>> too.
>> Now, Richard suggested doing something like:
>> 1) inline asm ("...")
>> 2) asm ("..." : : : : <size-expr>)
>> 3) asm ("...") __attribute__((asm_size(<size-expr>)));
>> with which user can tell gcc what the size of that inline asm
>> is and thus allow for more precise cost estimation and in the end
>> inlining.
>> And FWIW 3) looks pretty straight-forward to me because attributes
>> pretty common anyways.
>> But I'm sure there are other options and I'm sure people will have
>> better/different ideas so feel free to chime in.
>Thanks for taking care of it. I would like to mention a second issue,
>you may want to resolve both with a single solution: not inlining
>conditional __builtin_constant_p(), in which there are two code-paths -
>for constants and one for variables.
>Consider for example the Linux kernel ilog2 macro, which has a
>based on __builtin_constant_p() (
>). The compiler mistakenly considers the “heavy” code-path that is
>to be evaluated only in compilation time to evaluate the code size.

But this is a misconception about __builtin_constant_p. It doesn't guard sth like 'constexpr' regions. If you try to use it with those semantics you'll fail (appearantly you do).

Of course IPA CP code size estimates when seeing a constant fed to bcp might be not optimal, that's another issue of course.


>causes the kernel to consider functions such as kmalloc() as “big”.
>kmalloc() is marked with always_inline attribute, so instead the
>functions, such as kzalloc() are not inlined.
>When I thought about hacking gcc to solve this issue, I considered an
>intrinsic that would override the cost of a given statement. This
>is not too nice, but may solve both issues.
>In addition, note that AFAIU the impact of a wrong cost of code
>can also impact loop and other optimizations.

 \ /
  Last update: 2018-10-07 18:47    [W:0.180 / U:2.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site