[jba...@redhat.com: [PATCH 0/3] tracepoints: delay argument evaluation]

2009-05-20 Thread Jason Baron
hi,

While working on some Linux kernel code, I've found that functions that
are declared as 'static inline' are having their arguments evaluated
well before they are used. For example I have a function:

static inline void trace(arg1, arg2)
{
if (unlikely(enabled)) {

}
}

If i call 'trace(ptr->arg1, ptr->arg2)', then the pointers are
dereferenced before the 'if' is executed. Is there any way to delay the
argument evaluation until they are used? Am I missing a compiler option?
I am used gcc 4.3.0.

thanks,

-Jason


Re: [RFC] gcc feature request: Moving blocks into sections

2013-08-05 Thread Jason Baron

On 08/05/2013 03:40 PM, Marek Polacek wrote:

On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:

On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
 wrote:

Ugh. I can see the attraction of your section thing for that case, I
just get the feeling that we should be able to do better somehow.

Hmm.. Quite frankly, Steven, for your use case I think you actually
want the C goto *labels* associated with a section. Which sounds like
it might be a cleaner syntax than making it about the basic block
anyway.

FWIW, we also support hot/cold attributes for labels, thus e.g.

   if (bar ())
 goto A;
   /* ... */
A: __attribute__((cold))
   /* ... */

I don't know whether that might be useful for what you want or not though...

Marek



It certainly would be.

That was how I wanted to the 'static_key' stuff to work, but 
unfortunately the last time I tried it, it didn't move the text 
out-of-line any further than it was already doing. Would that be 
expected? The change for us, if it worked would be quite simple. 
Something like:


--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -21,7 +21,7 @@ static __always_inline bool arch_static_branch(struct 
static_key *key)

".popsection \n\t"
: :  "i" (key) : : l_yes);
return false;
-l_yes:
+l_yes: __attribute__((cold))
return true;
 }






Re: [RFC] gcc feature request: Moving blocks into sections

2013-08-05 Thread Jason Baron

On 08/05/2013 02:39 PM, Steven Rostedt wrote:

On Mon, 2013-08-05 at 11:20 -0700, Linus Torvalds wrote:


Of course, it would be good to optimize static_key_false() itself -
right now those static key jumps are always five bytes, and while they
get nopped out, it would still be nice if there was some way to have
just a two-byte nop (turning into a short branch) *if* we can reach
another jump that way..For small functions that would be lovely. Oh
well.

I had patches that did exactly this:

  https://lkml.org/lkml/2012/3/8/461

But it got dropped for some reason. I don't remember why. Maybe because
of the complexity?

-- Steve


Hi Steve,

I recall testing your patches and the text size increased unexpectedly. 
I believe I correctly accounted for changes to the text size *outside* 
of branch points. If you do re-visit the series that is one thing I'd 
like to double check/understand.


Thanks,

-Jason


Re: [RFC] gcc feature request: Moving blocks into sections

2013-08-05 Thread Jason Baron

On 08/05/2013 04:35 PM, Richard Henderson wrote:

On 08/05/2013 09:57 AM, Jason Baron wrote:

On 08/05/2013 03:40 PM, Marek Polacek wrote:

On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:

On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
 wrote:

Ugh. I can see the attraction of your section thing for that case, I
just get the feeling that we should be able to do better somehow.

Hmm.. Quite frankly, Steven, for your use case I think you actually
want the C goto *labels* associated with a section. Which sounds like
it might be a cleaner syntax than making it about the basic block
anyway.

FWIW, we also support hot/cold attributes for labels, thus e.g.

if (bar ())
  goto A;
/* ... */
A: __attribute__((cold))
/* ... */

I don't know whether that might be useful for what you want or not though...

 Marek


It certainly would be.

That was how I wanted to the 'static_key' stuff to work, but unfortunately the
last time I tried it, it didn't move the text out-of-line any further than it
was already doing. Would that be expected? The change for us, if it worked
would be quite simple. Something like:

It is expected.  One must use -freorder-blocks-and-partition, and use real
profile feedback to get blocks moved completely out-of-line.

Whether that's a sensible default or not is debatable.



Hi Steve,

I think if the 'cold' attribute on the default disabled static_key 
branch moved the text completely out-of-line, it would satisfy your 
requirement here?


If you like this approach, perhaps we can make something like this work 
within gcc. As its already supported, but doesn't quite go far enough 
for our purposes.


Also, if we go down this path, it means the 2-byte jump sequence is 
probably not going to be too useful.


Thanks,

-Jason