[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090924191642.GA19225@elte.hu>
Date: Thu, 24 Sep 2009 21:16:42 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: Jason Baron <jbaron@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>, Andi Kleen <ak@...e.de>,
linux-kernel@...r.kernel.org
Subject: Re: Immediate values
* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> * Jason Baron (jbaron@...hat.com) wrote:
> >
> > right we've proposed an alternative to the immediate values, which
> > I've been calling 'jump label', here:
> >
> > http://marc.info/?l=linux-kernel&m=125200966226921&w=2
> >
> > The basic idea is that gcc, 4.5 will have support for an 'asm goto'
> > construct which can refer to c code labels. Thus, we can replace a
> > nop in the code stream with a 'jmp' instruction to various branch
> > targets.
> >
> > In terms of a comparison between the two, IMO, I think that the
> > syntax for the immediate variables can be more readable, since it
> > just looks like a conditional expression.
> >
> > The immediate values do a 'mov', 'test' and then a jump, whereas
> > jump label can just do a jump. So in this respect, I believe jump
> > label can be more optimal. Additinally, if we want to mark sections
> > 'cold' so they don't impact the istruction cache, the jump label
> > already has the labels for doing so. Obviously, a performance
> > comparison would be interesting as well.
>
> For branches, I'm convinced that a "static jump" approach will beat
> immediate values anytime, because you save the BPB hit completely.
>
> However, there are other use-cases involving a variable read, and in
> that case immediate values are useful. Andi has been bugging me for a
> while to re-post this patchset, I'm pretty sure he has precise ideas
> about how he would like to use it.
It depends on how significant that usecase is.
Tracepoints used to be the biggest use-case for immediate values, and
without that the thing becomes rather complex to maintain, for probably
very little benefit.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists