LCC compiler optimizations in release mode

[menchar]

Will the native CVI compiler (LCC compiler), in release mode, optimize the following such that it won't work?

Module 1:  

int iFlag = 0;  // top level variable, defining declaration not declared as volatile or register

function1 () { while (1) {if (iFlag == 1) do something wonderful;}}   // reads the top level variable but never writes to it.  No other references to iFlag in module 1.

Module 2:

extern int iFlag   // top level variable, referencing declaration
function2 () {iFlag = 1; return;}

Function 2 runs in a callback, sets the flag to signal function 1, and exits.  function 1 reads the flag and does something wonderful.

Will the LCC compiler optimize function 1 and put the value of iFlag in a register rather than read it every time from memory?    I don't fully understand the sequence point concept in C89.  I think the compiler's not supposed to optimize across a sequence point:  so if there's a sequence point in between the top level variable and the reference, it should never try to optimize the reference to it in function 1.  I.e., the compiler is only allowed to optimize between sequence points.  

Thanks.

Menchar

[jr_2005]

---

@menchar wrote:

 I think the compiler's not supposed to optimize across a sequence point

---

I don't believe that is the case. There are a great many sequence points in normal code, including statement terminations, so such a restriction would result in very little optimisation. In the code sample you show, the correct approach is to declare iFlag as volatile, which will at least ensure consistant operation of code between different compilers, whether or not they have different optimisation settings/strategies.

JR

[menchar]

Thanks for the response.

Reading H & S it's not clear to me that this situation requires the volatile type qualifier.  If volatile were used, then the compiler is restricted to not optimizing across a sequence point.  Without it, it can.

H&S do mention using volatile type qualifier to provide reliable access to special memory locations used by computer hardware or by asynchronous processes such as interrupt handlers.  I guess the callback could be considered an asynchronous process, but generally speaking, you wouldn't ordinarily infer the possibility of an asynchronous process accessing all of your top level variables I wouldn't think.

In any event, we tried it and for this case, using the volatile type qualifier made no difference, the read-only reference to iFlag was not being optimized into a machine register.  Unless the compiler tries to optimize across functions within a module, it couldn't very well make a copy of iFlag to a register, since it could be written to by some other function within that same module, defeating the whole point of having a top level variable.  We had a different error that made it appear that we weren't writing / reading the top level variable, but in fact that mechanism was working OK.

Menchar

Message Edited by menchar on 06-27-2007 10:55 AM

Message Edited by menchar on 06-27-2007 10:57 AM