Disable optimizations on one function (was: 'pragma optimize' ...)

Disable optimizations on one function (was: 'pragma optimize' ...)

[Jeffrey Walton]

>> I have one more question related to the use of '#pragma GCC optimize'.
>> I have a zeroizer that must execute due to Certification and
>> Accreditation (C&A) requirements. When the zeroizer is removed as a
>> dead store, the compiler folks usually say, "but you asked for
>> optimizations...".
>>
>> If we cannot use '#pragma GCC optimize' to turn off the optimizer for
>> a function, then how do we tell the compiler to *not* remove the code?
>
> It is hard to tell without seeing the code. But see noclone, noinline
> entries at:
> http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>

As a simplified example, imagine I have a function ClearAndFree:

    void ClearAndFree(void* ptr, size_t n)
    {
        if(!ptr) return;

        memset(ptr, 0x00, n);
        free(ptr);
    }

We've seen these type of functions have the memset optimized away.

Many folks try and cast ptr to volatile, but that's an abuse because
GCC considers volatile something for memory mapped hardware. Volatile
should not be used in an attempt to tame the optimizer.

The trick mentioned with noinlne looks promising. Can I use 'asm
("");' to stop the optimizer from removing the call to memset? If so,
does the trick work with GCC 4.2.1 and above?

(GCC 4.2.1 and above is required because OpenBSD still provides it).

Jeff

Re: Disable optimizations on one function (was: 'pragma optimize' ...)

[Andrew Haley]

On 16/07/15 06:58, Jeffrey Walton wrote:
> Many folks try and cast ptr to volatile, but that's an abuse because
> GCC considers volatile something for memory mapped hardware. Volatile
> should not be used in an attempt to tame the optimizer.

GCC does not consider volatile to be something for memory mapped
hardware.  Volatile objects are simply those which may be modified in
ways unknown to the implementation or have other unknown side effects.
In other words, volatile is exactly the right thing use in the
ClearAndFree case.  But passing a volatile pointer to memset() is
pointless because the volatile qualifier will be discarded at the
point of call: you'll have to write the memory yourself.

If you don't mind being nonportable, a memoryclobber should do it:

    memset(ptr, 0x00, n);
    asm volatile("": : : "memory");

or even:

    memset(ptr, 0x00, n);
    __atomic_thread_fence(__ATOMIC_RELAXED);

Andrew.

Re: Disable optimizations on one function (was: 'pragma optimize' ...)

[Jeffrey Walton]

>> Many folks try and cast ptr to volatile, but that's an abuse because
>> GCC considers volatile something for memory mapped hardware. Volatile
>> should not be used in an attempt to tame the optimizer.
>
> GCC does not consider volatile to be something for memory mapped
> hardware.

OK, this appears to be creating a moving definition (or the definition
has changed since I took note of it). I took the last definition from
Ian Lance Taylor. See http://www.airs.com/blog/archives/154 and, for
example, https://gcc.gnu.org/ml/gcc-help/2012-03/msg00257.html.

> ...
> If you don't mind being nonportable, a memoryclobber should do it:
>
>     memset(ptr, 0x00, n);
>     asm volatile("": : : "memory");
>
> or even:
>
>     memset(ptr, 0x00, n);
>     __atomic_thread_fence(__ATOMIC_RELAXED);

Perfect, thanks.

Jeff

Re: Disable optimizations on one function (was: 'pragma optimize' ...)

[Andrew Haley]

On 16/07/15 10:40, Jeffrey Walton wrote:
>>> Many folks try and cast ptr to volatile, but that's an abuse because
>>> GCC considers volatile something for memory mapped hardware. Volatile
>>> should not be used in an attempt to tame the optimizer.
>>
>> GCC does not consider volatile to be something for memory mapped
>> hardware.
> 
> OK, this appears to be creating a moving definition (or the definition
> has changed since I took note of it). I took the last definition from
> Ian Lance Taylor. See http://www.airs.com/blog/archives/154 and, for
> example, https://gcc.gnu.org/ml/gcc-help/2012-03/msg00257.html.

Well, reluctant as I am to argue with Ian, the definition of volatile
I used is a direct quote from the standard.  There are problems with
volatile as defined, it's true: for example, nowhere is it specified
exactly what constitutes a memory access.  And Ian is quite right to
say that the standard doesn't guarantee that a pointer-to-volatile
should be handled as though it pointed to a volatile object.  But in
this case, with GCC, I think it's fine.

Andrew.

Re: Disable optimizations on one function (was: 'pragma optimize' ...)

[Jeffrey Walton]

On Thu, Jul 16, 2015 at 5:59 AM, Andrew Haley <aph@redhat.com> wrote:
> On 16/07/15 10:40, Jeffrey Walton wrote:
>>>> Many folks try and cast ptr to volatile, but that's an abuse because
>>>> GCC considers volatile something for memory mapped hardware. Volatile
>>>> should not be used in an attempt to tame the optimizer.
>>>
>>> GCC does not consider volatile to be something for memory mapped
>>> hardware.
>>
>> OK, this appears to be creating a moving definition (or the definition
>> has changed since I took note of it). I took the last definition from
>> Ian Lance Taylor. See http://www.airs.com/blog/archives/154 and, for
>> example, https://gcc.gnu.org/ml/gcc-help/2012-03/msg00257.html.
>
> Well, reluctant as I am to argue with Ian, the definition of volatile
> I used is a direct quote from the standard.  There are problems with
> volatile as defined, it's true: for example, nowhere is it specified
> exactly what constitutes a memory access.  And Ian is quite right to
> say that the standard doesn't guarantee that a pointer-to-volatile
> should be handled as though it pointed to a volatile object.  But in
> this case, with GCC, I think it's fine.
>
Yeah, it kind of crossed my wires for a moment. There's a handful of
folks I always listen to when it comes to GCC, and you and Ian are two
of them :o

If you tell me the memory barrier works to tame the optimizer for a
function, then that's what I will use.

Jeff

Re: Disable optimizations on one function (was: 'pragma optimize' ...)

[Martin Sebor]

On 07/15/2015 11:58 PM, Jeffrey Walton wrote:
>>> I have one more question related to the use of '#pragma GCC optimize'.
>>> I have a zeroizer that must execute due to Certification and
>>> Accreditation (C&A) requirements. When the zeroizer is removed as a
>>> dead store, the compiler folks usually say, "but you asked for
>>> optimizations...".
>>>
>>> If we cannot use '#pragma GCC optimize' to turn off the optimizer for
>>> a function, then how do we tell the compiler to *not* remove the code?
>>
>> It is hard to tell without seeing the code. But see noclone, noinline
>> entries at:
>> http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>>
>
> As a simplified example, imagine I have a function ClearAndFree:
>
>      void ClearAndFree(void* ptr, size_t n)
>      {
>          if(!ptr) return;
>
>          memset(ptr, 0x00, n);
>          free(ptr);
>      }
>
> We've seen these type of functions have the memset optimized away.

(This is why the memset_s function was added to the C standard.)

The call to memset is optimized away because GCC knows both its
semantics and those of free. To prevent the memset from being
optimized away you must make it "believe" the semantics could
be different. There are a number of ways to do that: compiling
the function with the -fno-builtin-memset option (or one it's
enabled by) is one. Another is by hiding the memset call somehow,
e.g., by calling the function via a pointer initialized outside
the calling function, or by calling the function from an asm
statement.

Martin