[PATCH] [ARM] Introduce patching of phys_to_virt and vice versa

[Nicolas Pitre]

On Tue, 28 Sep 2010, Eric Miao wrote:

> On Tue, Aug 10, 2010 at 12:55 AM, Nicolas Pitre <nico at fluxnic.net> wrote:
> > On Sun, 8 Aug 2010, Russell King - ARM Linux wrote:
> >
> >> On Fri, Aug 06, 2010 at 01:07:46PM -0400, Nicolas Pitre wrote:
> >> > No idea.  That depends how gcc is considering inline asm.  Given there
> >> > is one input operand, I suppose gcc would account for the delay slot
> >> > before that operand is actually available.
> >>
> >> For something which could very well become by default enabled across
> >> the board - due to the push to have a single kernel binary for lots
> >> of significantly different platforms - it seems little research has
> >> been carried out on this point.
> >>
> >> While I agree that other obvious solutions would be more expensive, I
> >> think it makes sense to have the commit which is introducing this
> >> method include a proper evaluation, not least so that people who need
> >> to make the decision to enable this aren't repeating the same research
> >> that someone else has done (or, worse, just decide to enable it 'just
> >> because' without any understanding of what the effect may be.)
> >
> > Sure, I agree.  I'll contact gcc people for a definitive answer.
> >
> 
> Nico, any feedback?

Yes.  As far as scheduling goes, the current gcc implementation simply 
considers any inline assembly as a pipeline flush.  This is not perfect, 
but without the volatile this is still acceptable as demonstrated by 
your comparison example, probably better than dereferencing a global 
variable.  I'll ask the Linaro toolchain group to see if it is 
possible to improve gcc for this, but I suspect the improvement would be 
marginal compared to the current results.

> >> I think we also need to consider whether the volatile is really required.
> >> This asm() doesn't have any side effects other than its output operand,
> >> so I suspect that the volatile may get in the way of some optimisations
> >> (such as deleting the operation if the output is not actually used.)
> >
> > Indeed, the volatile should go.  This is even getting in the way of
> > better scheduling.
> >
> 
> Yep. I don't see the necessity here for the volatile. Actually after removing
> it, it resulted a better instruction scheduling.

Indeed.  The volatile qualifier for inline assembly is a big hammer 
preventing any code movement around and across them.


Nicolas