llvm dev - Jun 2013 - [LLVMdev] [cfe-dev] [RFC] add Function Attribute to disable optimization

On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at gmail.com>
wrote:
>
>
> First is to ensure dead-writes are not removed. For example, a
> function that zeroizes or wipes memory is subject to removal during
> optimization. I often have to look at program's disassembly to ensure
> the memset is not removed by the optimizer.
>
Appropriate use of `volatile` is probably sufficient for this use case.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130617/75428094/attachment.html>

On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <silvas at purdue.edu>
wrote:
> On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at
gmail.com> wrote:
>> First is to ensure dead-writes are not removed. For example, a
>> function that zeroizes or wipes memory is subject to removal during
>> optimization. I often have to look at program's disassembly to
ensure
>> the memset is not removed by the optimizer.
>
> Appropriate use of `volatile` is probably sufficient for this use case.
That brings up a good point. As I understand it, volatile is
essentially implementation defined. What is Clang/LLVM's
interpretation?

Here's what I know. Microsoft's interpretation allows me to use
volatile for the situation under MSVC++ [1]. GCC's interpretation of
volatile is for memory mapped hardware, so it does not allow me to use
the qualifier to tame the optimizer [2].

Jeff

[1] http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx
[2] http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html

On Mon, Jun 17, 2013 at 3:32 PM, Jeffrey Walton <noloader at gmail.com>
wrote:
> On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <silvas at purdue.edu>
wrote:
> > On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at
gmail.com>
> wrote:
> >> First is to ensure dead-writes are not removed. For example, a
> >> function that zeroizes or wipes memory is subject to removal
during
> >> optimization. I often have to look at program's disassembly to
ensure
> >> the memset is not removed by the optimizer.
> >
> > Appropriate use of `volatile` is probably sufficient for this use
case.
> That brings up a good point. As I understand it, volatile is
> essentially implementation defined. What is Clang/LLVM's
> interpretation?
>
> Here's what I know. Microsoft's interpretation allows me to use
> volatile for the situation under MSVC++ [1]. GCC's interpretation of
> volatile is for memory mapped hardware, so it does not allow me to use
> the qualifier to tame the optimizer [2].
>
>
clang doesn't treat volatile loads/stores as aquire/release barriers, if
that's what you're asking.

Actually, if you look at the 2012 version of the docs "
http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd(v=vs.110).aspx",
you can see Microsoft was forced to change its own rules so as to not
completely screw over performance on non-X86 platforms.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130617/c42a0ba5/attachment.html>

On Mon, Jun 17, 2013 at 3:32 PM, Jeffrey Walton <noloader at gmail.com>
wrote:
> On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <silvas at purdue.edu>
wrote:
> > On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at
gmail.com>
> wrote:
> >> First is to ensure dead-writes are not removed. For example, a
> >> function that zeroizes or wipes memory is subject to removal
during
> >> optimization. I often have to look at program's disassembly to
ensure
> >> the memset is not removed by the optimizer.
> >
> > Appropriate use of `volatile` is probably sufficient for this use
case.
> That brings up a good point. As I understand it, volatile is
> essentially implementation defined. What is Clang/LLVM's
> interpretation?
>
> Here's what I know. Microsoft's interpretation allows me to use
> volatile for the situation under MSVC++ [1]. GCC's interpretation of
> volatile is for memory mapped hardware, so it does not allow me to use
> the qualifier to tame the optimizer [2].
>
> Jeff
>
> [1]
> http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx
> [2] http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html

`volatile` roughly means "this memory access may have side effects beyond
those of regular memory". Since the compiler can't reason about these
memory accesses, it is forced to carry them down to the assembly "as
written" without tampering with them. AFAIK `volatile` is sufficient for
making loads and stores unelidable (which was your original use case).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130617/39111b59/attachment.html>