Hi!

On Sun, Dec 02, 2018 at 06:23:23PM +0100, Marc Glisse wrote:
> On Sun, 2 Dec 2018, Segher Boessenkool wrote:
> 
> >diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> >index 5aa782b..7e9ed99 100644
> >--- a/gcc/tree-inline.c
> >+++ b/gcc/tree-inline.c
> >@@ -4109,6 +4109,9 @@ estimate_num_insns (gimple *stmt, eni_weights 
> >*weights)
> >        with very long asm statements.  */
> >     if (count > 1000)
> >       count = 1000;
> >+    /* If this asm is asm inline, count anything as minimum size.  */
> >+    if (gimple_asm_inline_p (as_a <gasm *> (stmt)))
> >+      count = !!count;
> >     return MAX (1, count);
> >      }
> 
> what is the point of !!count when we take the max with 1 on the very
> next line? Is it in prevision of a time when we may remove the MAX? (sorry 
> if this was covered in previous iterations)
> 
> By the way, not related to the patch, but I wonder why we cannot have a
> cost of 0.

That exactly is the point :-)  My code still works if you remove that MAX
expression, as hopefully we will some day.  Right now GCC will of course
optimise it to "count = 1;", but writing it like that doesn't make the
intent clear.

I think this workaround is here because otherwise we get infinite recursion
in the inliner, but that of course should be fixed, not worked around.
Ideally.  If anyone ever has time for it.  :-)

> My main use of inline asm is as an optimization barrier:
> asm("":"+gx"(local_var))
> possibly marked volatile to prevent more optimizations. I certainly
> expect it to generate exactly 0 instruction in most cases. Although if I 
> am not careful it could easily generate moves from x87 to sse/memory for 
> instance. I guess a minimal cost is safer and doesn't affect decisions too 
> badly.

This is only for inlining; GCC _does_ know such asms are cost 0, and uses
that for all other purposes.

("gx", btw?  Is that a typo?  Or, on what target is "x" useful here?)


Segher

Reply via email to