Prev: [GIT PULL 0/1] perf/core improvements
Next: [PATCH 1/1] perf tools: Add DWARF register lookup for SH
From: Jeremy Fitzhardinge on 15 Jul 2010 10:40
On 07/14/2010 06:29 PM, H. Peter Anvin wrote:
> Yes, it will definitely NOT be pruned. I'm going to file a gcc documentation request to see if any of this is actually needed, though. There may also be a need for gcc to handle *inbound* general memory constraints.
>

You mean "depends on all prior memory updates"? We have been relying on
"memory" to do that (barrier(), for example), but it would be nice to
explicitly confirm that's OK, or get something which is guaranteed to be OK.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 15 Jul 2010 15:00
On 07/15/2010 07:34 AM, Jeremy Fitzhardinge wrote:
> On 07/14/2010 06:29 PM, H. Peter Anvin wrote:
>> Yes, it will definitely NOT be pruned. I'm going to file a gcc documentation request to see if any of this is actually needed, though. There may also be a need for gcc to handle *inbound* general memory constraints.
>>
>
> You mean "depends on all prior memory updates"? We have been relying on
> "memory" to do that (barrier(), for example), but it would be nice to
> explicitly confirm that's OK, or get something which is guaranteed to be OK.
>

No, we haven't. You're misunderstanding what a "memory" clobber does.
A clobber affects the output side only, but doesn't inherently provide
ordering on the input side. Apparently this is implicit in "asm
volatile", which is a very important property.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 15 Jul 2010 15:30
On 07/15/2010 11:54 AM, H. Peter Anvin wrote:
> No, we haven't. You're misunderstanding what a "memory" clobber does.
> A clobber affects the output side only, but doesn't inherently provide
> ordering on the input side. Apparently this is implicit in "asm
> volatile", which is a very important property.

OK. It would be nice to get that confirmed.

J

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 15 Jul 2010 15:40
On 07/15/2010 12:28 PM, Jeremy Fitzhardinge wrote:
> On 07/15/2010 11:54 AM, H. Peter Anvin wrote:
>> No, we haven't. You're misunderstanding what a "memory" clobber does.
>> A clobber affects the output side only, but doesn't inherently provide
>> ordering on the input side. Apparently this is implicit in "asm
>> volatile", which is a very important property.
>
> OK. It would be nice to get that confirmed.
>

The section in the docs (gcc 4.4.4 section 5.37) reads as:

If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You will also want to add the `volatile' keyword if the memory affected
is not listed in the inputs or outputs of the `asm', as the `memory'
clobber does not count as a side-effect of the `asm'. If you know how
large the accessed memory is, you can add it as input or output but if
this is not known, you should add `memory'.

This was clearer to me when I read it last evening, either because I was
tired and on an airplane ;) or because I read too much into it... it's
worth noting that an asm() in gcc is really nothing more than an
internal compiler event exposed to the user; the terms "output", "input"
and "clobber" have pretty specific meaning in compiler theory, and they
at least appear to be used that way.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 15 Jul 2010 16:00
On 07/15/2010 12:36 PM, H. Peter Anvin wrote:
> On 07/15/2010 12:28 PM, Jeremy Fitzhardinge wrote:
>
>> On 07/15/2010 11:54 AM, H. Peter Anvin wrote:
>>
>>> No, we haven't. You're misunderstanding what a "memory" clobber does.
>>> A clobber affects the output side only, but doesn't inherently provide
>>> ordering on the input side. Apparently this is implicit in "asm
>>> volatile", which is a very important property.
>>>
>> OK. It would be nice to get that confirmed.
>>
>>
> The section in the docs (gcc 4.4.4 section 5.37) reads as:
>
> If your assembler instructions access memory in an unpredictable
> fashion, add `memory' to the list of clobbered registers. This will
> cause GCC to not keep memory values cached in registers across the
> assembler instruction and not optimize stores or loads to that memory.
> You will also want to add the `volatile' keyword if the memory affected
> is not listed in the inputs or outputs of the `asm', as the `memory'
> clobber does not count as a side-effect of the `asm'. If you know how
> large the accessed memory is, you can add it as input or output but if
> this is not known, you should add `memory'.
>
> This was clearer to me when I read it last evening, either because I was
> tired and on an airplane ;) or because I read too much into it...

Yes, I think it reads fairly ambigiously. The first two and last
sentences definitely read as if "memory" not only says that all memory
could be modified by the asm, but could also be used as an input by the
asm, and therefore prevents two-way reordering of the asm with respect
to memory operations.

But I don't know how to parse the "volatile" sentence, I guess because
they're using the term "side-effect" in a *very* specific way which
means something other than "accessed in an unpredictable way". Maybe
the memory clobber means it doesn't cache things in registers, but the
most recent version of some memory contents may not be stored in its
"home" location? Or something to do with alias analysis?

> it's
> worth noting that an asm() in gcc is really nothing more than an
> internal compiler event exposed to the user; the terms "output", "input"
> and "clobber" have pretty specific meaning in compiler theory, and they
> at least appear to be used that way.
>

Yes, and it means they're stuck trying to support a compiler-internal
implementation as an external API. But it really means you end up
having to go to the source and rummage around in md files to really work
out what the syntax is, let alone what the more subtle semantics are.

J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [GIT PULL 0/1] perf/core improvements
Next: [PATCH 1/1] perf tools: Add DWARF register lookup for SH