Re: [PATCH 2.6.13-rc1 07/10] IOCHK interface for I/O error handling/detecting

From: david mosberger <dmosberger_at_gmail.com>
Date: 2005-07-09 05:23:54
On 7/8/05, Luck, Tony <tony.luck@intel.com> wrote:
> Cc: list was trimmed because I'm only discussing ia64 issue here.
> 
> >I'm not familiar with assembly code for intel compiler. So David,
> >could you write another macro of ia64_mca_barrier() or a proper
> >subroutine instead?
> 
> Each of the uses of ia64_mca_barrier() is like this ...
> 
>         val = *(... *)addr; /* read from I/O address */
> 
>         ia64_mca_barrier(val); /* consume result */
> 
>         return val;
> 
> Now it appears to me that if you just define ia64_mca_barrier()
> as an empty function (in C):
> 
> void
> ia64_mca_barrier(unsigned long v)
> {
> }
> 
> then this will force a consumption of the value (since the compiler
> will have to copy it from whatever register it was in to an "out"
> register to pass to the function).  Without the call, then the
> compiler will probably allocate "r8" for "val" ... so there will
> be no consumption.

I don't think this is really safe.  There is nothing to stop the
compiler from loading the value directly into the out register, which
would again defer consumption of the value (especially if the caller
of ia64_mca_barrier() got inlined itself.

In my opinion, it would be safest to write this in assembly, so we're
_guaranteed_ it will do what we want, no matter how smart the
compilers get.  Something along the lines of:

ia64_mca_barrier:
   mov r8 = r32
   br.ret.sptk.many rp

should do (and I agree that this function needs a comment).

  --david
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Jul 8 15:29:02 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:40 EST