[cfe-dev] [RFC] add Function Attribute to disable optimization

Joshua Cranmer 🐧 Pidgeot18 at gmail.com
Mon Jun 17 16:19:08 PDT 2013


On 6/17/2013 5:32 PM, Jeffrey Walton 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?

Volatile has an explicit definition in C99/C11/C++03/C++11, and it's 
roughly the same in all of them. Volatile objects "may be modified in 
ways unknown to the
implementation or have other unknown side effects" (to quote C99), and 
the implementation must therefore preserve the accesses and their order 
even when optimizing.

> 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].

Microsoft decided that they wanted to add additional semantics to 
volatile to make it enforce load/store barriers for multithreaded code. 
Since C11 and C++11 added explicit support for multithreaded atomic 
operations and memory models, those extra semantics are unnecessary; 
with the introduction of a processor with a relaxed memory model, it's 
also undesirable.

For as vague as your description is, volatile appears to be sufficient 
for your use case (it's incorrect with respect to multithreaded memory 
visibility issues, but it's no less correct than not optimizing the code).

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist




More information about the cfe-dev mailing list