asm in inline function invalidating function attributes?

asm in inline function invalidating function attributes?

[Ulrich Drepper]

I think gcc should allow the programmer to tell it something about a
function return value even if the function is inlined and the compiler
can see all the code.  Consider the code below.

If NOINLINE is defined the compiler will call g once.  No need to do
anything after the h() call since the function is marked const.

If NOINLINE is not defined and the compiler sees the asm statement it
will expand the function body twice.  Don't worry about the content of
the asm, this is correct in the case I care about.  What I expect is
that gcc still respects that the function is marked const and performs
the same optimization as in the case when the function is not inlined.

Is there anything I miss how to achieve this?  I don't think so in
which case, do people agree that this should be changed?


extern int **g(void) __attribute__((const, nothrow));
#ifndef NOINLINE
extern inline int ** __attribute__((always_inline, const, nothrow,
gnu_inline, artificial)) g(void) {
  int **p;
  asm ("call g@plt" : "=a" (p));
  return p;
}
#endif

#define pr(c) ((*g())[c] & 0x80)

extern void h(void);

int
f(const char *s)
{
  int c = 0;
  for (int i = 0; i < 20; ++i)
    c |= pr(s[i]);

  h();

  for (int i = 20; i < 40; ++i)
    c |= pr(s[i]);

  return c;
}

Re: asm in inline function invalidating function attributes?

[Richard Guenther]

On Sat, Oct 15, 2011 at 11:52 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> I think gcc should allow the programmer to tell it something about a
> function return value even if the function is inlined and the compiler
> can see all the code.  Consider the code below.
>
> If NOINLINE is defined the compiler will call g once.  No need to do
> anything after the h() call since the function is marked const.
>
> If NOINLINE is not defined and the compiler sees the asm statement it
> will expand the function body twice.  Don't worry about the content of
> the asm, this is correct in the case I care about.  What I expect is
> that gcc still respects that the function is marked const and performs
> the same optimization as in the case when the function is not inlined.
>
> Is there anything I miss how to achieve this?  I don't think so in
> which case, do people agree that this should be changed?

It's difficult to do this in general given that we give up for
statements in most optimization passes that would make
the function not auto-discovered as const (that is, a volatile
asm such as yours).

So the case boils down to a optimization phase ordering issue.
While we do CSE before inlining the function the CSE opportunity
is only discovered after doing loop invariant motion - which is done
way after we inlined the function (and you can probably see that
the asm() is not considered loop invariant either).

The question is now, of course why you need to emit calls
from an asm() statement, something which isn't guaranteed
to work anyway (IIRC).

Richard.

>
> extern int **g(void) __attribute__((const, nothrow));
> #ifndef NOINLINE
> extern inline int ** __attribute__((always_inline, const, nothrow,
> gnu_inline, artificial)) g(void) {
>  int **p;
>  asm ("call g@plt" : "=a" (p));
>  return p;
> }
> #endif
>
> #define pr(c) ((*g())[c] & 0x80)
>
> extern void h(void);
>
> int
> f(const char *s)
> {
>  int c = 0;
>  for (int i = 0; i < 20; ++i)
>    c |= pr(s[i]);
>
>  h();
>
>  for (int i = 20; i < 40; ++i)
>    c |= pr(s[i]);
>
>  return c;
> }
>

Re: asm in inline function invalidating function attributes?

[Ulrich Drepper]

On Sun, Oct 16, 2011 at 06:31, Richard Guenther
<richard.guenther@gmail.com> wrote:
> The question is now, of course why you need to emit calls
> from an asm() statement, something which isn't guaranteed
> to work anyway (IIRC).

It's not guaranteed to work in general.  The problem to solve is that
I know the function which is called is not clobbering any registers.
If I leave it with the normal function call gcc has to spill
registers.  If I can hide the function call the generated code can be
significantly better.

An alternative solution would be to have a function attribute which
allows me to specify which registers are clobbered.  Or at least an
attribute which says none are clobbered.

Re: asm in inline function invalidating function attributes?

[Jakub Jelinek]

On Sat, Oct 15, 2011 at 05:52:03PM -0400, Ulrich Drepper wrote:
> I think gcc should allow the programmer to tell it something about a
> function return value even if the function is inlined and the compiler
> can see all the code.  Consider the code below.

If this is about e.g.
2011-09-14  Ulrich Drepper  <drepper@gmail.com>

	* sysdeps/x86_64/fpu/bits/mathinline.h (__MATH_INLINE): Use
	__extern_always_inline.
	Define lrint{f,} and llrint{f,} for 64-bit and in some situations for
 	32-bit.
then I'd say these inlines are the wrong direction, gcc (tried 4.6/trunk
only) has lrint{,f,l} builtin, and for -ffast-math it will optimize it into
cvtsd2siq etc. (both for -m64 and for -m32 -msse2 -mfmath=sse). 
It will be handled as const, and furthermore gcc will constant fold it
(lrint (7.5) will be resolved at compile time).

	Jakub

Re: asm in inline function invalidating function attributes?

[Ulrich Drepper]

On Sun, Oct 16, 2011 at 14:38, Jakub Jelinek <jakub@redhat.com> wrote:
> If this is about e.g.
> 2011-09-14  Ulrich Drepper  <drepper@gmail.com>
>
>        * sysdeps/x86_64/fpu/bits/mathinline.h (__MATH_INLINE): Use
>        __extern_always_inline.
>        Define lrint{f,} and llrint{f,} for 64-bit and in some situations for
>        32-bit.

No, something else.  It's about the calls to __ctype_b_loc etc.  The
function just returns a pointer, nothing else.

Re: asm in inline function invalidating function attributes?

[Andi Kleen]

Ulrich Drepper <drepper@gmail.com> writes:
>
> It's not guaranteed to work in general.  The problem to solve is that
> I know the function which is called is not clobbering any registers.
> If I leave it with the normal function call gcc has to spill
> registers.  If I can hide the function call the generated code can be
> significantly better.

iirc the new shrink wrapping support that just went in was to address
problems like that. Perhaps try a mainline compiler?

But I agree that such an attribute would be useful. I would use it.

At least the Linux kernel has a couple such cases ("nasty inline asm to
hide register clobbering in calls") and it's always ugly and hard to
maintain.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only

Re: asm in inline function invalidating function attributes?

[Richard Guenther]

On Mon, Oct 17, 2011 at 1:36 AM, Andi Kleen <andi@firstfloor.org> wrote:
> Ulrich Drepper <drepper@gmail.com> writes:
>>
>> It's not guaranteed to work in general.  The problem to solve is that
>> I know the function which is called is not clobbering any registers.
>> If I leave it with the normal function call gcc has to spill
>> registers.  If I can hide the function call the generated code can be
>> significantly better.
>
> iirc the new shrink wrapping support that just went in was to address
> problems like that. Perhaps try a mainline compiler?
>
> But I agree that such an attribute would be useful. I would use it.
>
> At least the Linux kernel has a couple such cases ("nasty inline asm to
> hide register clobbering in calls") and it's always ugly and hard to
> maintain.

It would simply be an alternate ABI that makes all registers callee-saved?
I suppose that would be not too hard to add.

Richard.

> -Andi
> --
> ak@linux.intel.com -- Speaking for myself only
>

Re: asm in inline function invalidating function attributes?

[Ulrich Drepper]

On Mon, Oct 17, 2011 at 02:57, Richard Guenther
<richard.guenther@gmail.com> > It would simply be an alternate ABI
that makes all registers callee-saved?
> I suppose that would be not too hard to add.

That would be great.  There are quite a few interfaces which have a
trivial normal case and only in special situations you need something
more.  These interfaces could be translated into:

retval fct(sometype arg) { return cond ? somevalue : complexfct(); }

These would be candidates for this new ABI.  The compiler might have
to do minimal spilling to implement the 'cond' expression but the new
ABI would be used unwise if this is expensive.

Note that I would want registers used for passing parameters to also
be preserved (except, of course, when they are needed for the return
value).  This proved really useful in the kernel syscall interface
which behaves like that.

Re: asm in inline function invalidating function attributes?

[Andi Kleen]

> > At least the Linux kernel has a couple such cases ("nasty inline asm to
> > hide register clobbering in calls") and it's always ugly and hard to
> > maintain.
> 
> It would simply be an alternate ABI that makes all registers callee-saved?

Yes exactly that.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.