On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> impacts inlining decisions badly, since GCC assumes cost of the asm to be
> high, even though it emits just one instruction to the text section. I'd
> like to point out that branch range optimization is also negatively affected.
The "length" of an asm is currently calculated as a conservatively correct
number (which you can trick of course, but that aside). This is on purpose.
This is also documented. And you are destroying this.
> Kernels developers can then use this extension via
>
> [if gcc-9 or compatible]
> #define ASM_NONTEXT_BEGIN "%`\n"
> [else]
> #define ASM_NONTEXT_BEGIN "\n"
> [endif]
>
> #define ASM_NONTEXT_END ASM_NONTEXT_BEGIN
Have you tested this? This counts everything as being longer than you
supposedly want.
> +@item %`
> +Signifies a boundary of a region where instruction separators are not
> +counted towards its cost (@pxref{Size of an asm}). Must be followed by
> +a whitespace character.
> @end table
It's not cost.
> +Likewise, it is possible for GCC to significantly over-estimate the
> +number of instructions in an @code{asm}, resulting in suboptimal decisions
> +when the estimate is used during inlining and branch range optimization.
GCC estimates the size of an asm conservatively. Without this you get
ICEs all over the place. Any proposed "adjust inlining cost of inline asm"
extension that adjusts instruction length instead (and can change it to too
low) will cause us too much trouble, and users a bad experience using the
compiler. IMO of course.
> + /* Leave room for future extensions. */
> + if (*p && !ISSPACE (*p))
> + output_operand_lossage ("%%` must be followed by whitespace");
What does that mean? And, why?
This isn't documented either.
> + if (in_backticks)
> + output_operand_lossage ("missing closing %%`");
Why?
Segher
