I have written an if-clause that checks whether I should break the program for debugging or not:
if (a < 0) {
a = a;
}
a should not become negative, but I have found that it does, and I want to break for debugging to see why it becomes negative if that happens, hence I have written this if-clause. On the line a = a; I have set a breakpoint, which is supposed to stop the program if it enters the if-clause. The thing is that the line doesn't do anything (which is necessary in order not to mess anything up), so the line is optimized away and the breakpoint ends up after the if-clause. This trick usually works but apparently the compiler wasn't very found of it this time.
The language is C++, and I'm compiling with qmake (a Qt tool) and mingw.
My question is, how can I prevent the compiler from optimizing away lines of code when I have breakpoints set on them? Or is there some other way to conditionally break the program for debugging?
One possibility is to call an I/O function. In Java, one could write:
if (a < 0) {
System.out.printf("");
}
Similarly, in C/C++, one could write:
if (a < 0) {
printf("");
}
Even though the function call is effectively a no-op, the compiler doesn't know that, and is unlikely to optimize the call away.
Or is there some other way to conditionally break the program for debugging?
Many modern IDE allow one to set conditional breakpoints: Visual Studio, Eclipse.
I usually put a printf (or cout, or whatever is appropriate for the language that you are using) here so that I can set a breakpoint, e.g.
if (a < 0) {
printf("a < 0 !\n"); // <<< set breakpoint here
}
If it's C or C++, simply defining a as volatile should help.
I defined a NO_OP() macro which doesn't do anything and doesn't require the file that's using it to include any header files:
#define NO_OP() {float f = 0; if (f != 0) exit(0);}
I don't know if the compiler will be able to optimize this macro away, but it works for me with MinGW.
It’s not portable, but with MSVC I use __asm nop (surrounded by #ifndef NDEBUG…#endif if the code is likely to remain in place for a while) to insert a literal no-op that I know the compiler won’t touch.
Related
What constantly happens to me is this, when I'm using Xcode with Objective-C:
I'll be writing a switch/case statement. Typically, to make sure statements are separated, the programmer must make sure there are break;s between cases.
I often forget to put the break; statement in, so instead of the device executing only the the desired case, the device executes the case and then the case after it. This happens on both a physical device (iPhone 6) and on every simulated device on iOS Simulator.
Here's what the syntax of the failed statement looks like, with someInt being a number that is either 0 or 1:
switch (someInt)
{
case 0:
{
// some statements to execute if "someInt" is 0
}
case 1:
{
// some statements to execute if "someInt" is 1
break;
}
}
Note how, in case 0:, there is no break; statement. This causes case 0: to execute and then case 1 to execute, instead of just case 0 to execute.
Is there a way I can put a flag in Xcode so it warns me if I forget a break; statement?
I know many programmers have probably been confused for days, weeks on end, because of this problem.
I do not think that there is a compiler warning. This is, because "the programmer must make sure there are breaks between cases." is not fully correct. The programmer must make sure that there are breaks between the cases, if he wants the code not to fall through. (There are use cases for falling through.)
The background is that C was akin of replacement for assembler. In assembler you write a multi-selection with conditional jumps to the specific branch (case) and unconditionally jumps out of a branch (break), if you do not want to continue. (BTW: This is the reason for being case-branches no blocks, too.)
Of course, this is obsolete. You can simply use the automatic code generation of Xcode or replace switches with if-else if-else cascades.
This behaviour is an implicit part of the C language (which underlies Objective C) and although more often than not, you don't want the fall through to the next case, for better or worse, this is the way the language is defined.
Swift, on the other hand, doesn't require an explicit break as cases do not fall through.
Clang does define a warning -Wimplicit-fallthrough which generates a warning in the situation you describe, however it doesn't seem to be supported in the Clang included with Xcode 6.3.2. I don't have Xcode 7 installed yet to check if this is still true in that version.
I'm wrestling with the concept of code "order of execution" and so far my research has come up short. I'm not sure if I'm phrasing it incorrectly, it's possible there is a more appropriate term for the concept. I'd appreciate it if someone could shed some light on my various stumbling blocks below.
I understand that if you call one method after another:
[self generateGrid1];
[self generateGrid2];
Both methods are run, but generateGrid1 doesn't necessarily wait for generateGrid2. But what if I need it to? Say generateGrid1 does some complex calculations (that take an unknown amount of time) and populate an array that generateGrid2 uses for it's calculations? This needs to be done every time an event is fired, it's not just a one time initialization.
I need a way to call methods sequentially, but have some methods wait for others. I've looked into call backs, but the concept is always married to delegates in all the examples I've seen.
I'm also not sure when to make the determinate that I can't reasonably expect a line of code to be parsed in time for it to be used. For example:
int myVar = [self complexFloatCalculation];
if (myVar <= 10.0f) {} else {}
How do I determine if something will take long enough to implement checks for "Is this other thing done before I start my thing". Just trial and error?
Or maybe I'm passing a method as parameter of another method? Does it wait for the arguments to be evaluated before executing the method?
[self getNameForValue:[self getIntValue]];
I understand that if you call one method after another:
[self generateGrid1];
[self generateGrid2];
Both methods are run, but generateGrid1 doesn't necessarily wait for generateGrid2. But what if I need it to?
False. generateGrid1 will run, and then generateGrid2 will run. This sequential execution is the very basis of procedural languages.
Technically, the compiler is allowed to rearrange statements, but only if the end result would be provably indistinguishable from the original. For example, look at the following code:
int x = 3;
int y = 4;
x = x + 6;
y = y - 1;
int z = x + y;
printf("z is %d", z);
It really doesn't matter whether the x+6 or the y-1 line happens first; the code as written does not make use of either of the intermediate values other than to calculate z, and that can happen in either order. So if the compiler can for some reason generate more efficient code by rearranging those lines, it is allowed to do so.
You'd never be able to see the effects of such rearranging, though, because as soon as you try to use one of those intermediate values (say, to log it), the compiler will recognize that the value is being used, and get rid of the optimization that would break your logging.
So really, the compiler is not required to execute your code in the order provided; it is only required to generate code that is functionally identical to the code you provided. This means that you actually can see the effects of these kinds of optimizations if you attach a debugger to a program that was compiled with optimizations in place. This leads to all sorts of confusing things, because the source code the debugger is tracking does not necessarily match up line-for-line with the code the compiled code the compiler generated. This is why optimizations are almost always turned off for debug builds of a program.
Anyway, the point is that the compiler can only do these sorts of tricks when it can prove that there will be no effect. Objective-c method calls are dynamically bound, meaning that the compiler has absolutely no guarantee about what will actually happen at runtime when that method is called. Since the compiler can't make any guarantees about what will happen, the compiler will never reorder Objective-C method calls. But again, this just falls back to the same principle I stated earlier: the compiler may change order of execution, but only if it is completely imperceptible to the user.
In other words, don't worry about it. Your code will always run top-to-bottom, each statement waiting for the one before it to complete.
In general, most method calls that you see in the style you described are synchronous, that means they'll have the effect you desire, running in the order the statements were coded, where the second call will only run after the first call finishes and returns.
Also, when a method takes parameters, its parameters are evaluated before the method is called.
I have a simple c program for printing n Fibonacci numbers and I would like to compile it to ELF object file. Instead of setting the number of fibonacci numbers (n) directly in my c code, I would like to set them in the registers since I am simulating it for an ARM processor.How can I do that?
Here is the code snippet
#include <stdio.h>
#include <stdlib.h>
#define ITERATIONS 3
static float fib(float i) {
return (i>1) ? fib(i-1) + fib(i-2) : i;
}
int main(int argc, char **argv) {
float i;
printf("starting...\n");
for(i=0; i<ITERATIONS; i++) {
printf("fib(%f) = %f\n", i, fib(i));
}
printf("finishing...\n");
return 0;
}
I would like to set the ITERATIONS counter in my Registers rather than in the code.
Thanks in advance
The register keyword can be used to suggest to the compiler that it uses a registers for the iterator and the number of iterations:
register float i;
register int numIterations = ITERATIONS;
but that will not help much. First of all, the compiler may or may not use your suggestion. Next, values will still need to be placed on the stack for the call to fib(), and, finally, depending on what functions you call within your loop, code in the procedure are calling could save your register contents in the stack frame at procedure entry, and restore them as part of the code implementing the procedure return.
If you really need to make every instruction count, then you will need to write machine code (using an assembly language). That way, you have direct control over your register usage. Assembly language programming is not for the faint of heart. Assembly language development is several times slower than using higher level languages, your risk of inserting bugs is greater, and they are much more difficult to track down. High level languages were developed for a reason, and the C language was developed to help write Unix. The minicomputers that ran the first Unix systems were extremely slow, but the reason C was used instead of assembly was that even then, it was more important to have code that took less time to code, had fewer bugs, and was easier to debug than assembler.
If you want to try this, here are the answers to a previous question on stackoverflow about resources for ARM programming that might be helpful.
One tactic you might take is to isolate your performance-critical code into a procedure, write the procedure in C, the capture the generated assembly language representation. Then rewrite the assembler to be more efficient. Test thoroughly, and get at least one other set of eyeballs to look the resulting code over.
Good Luck!
Make ITERATIONS a variable rather than a literal constant, then you can set its value directly in your debugger/simulator's watch or locals window just before the loop executes.
Alternatively as it appears you have stdio support, why not just accept the value via console input?
The documentation for __assume says "The most common use of __assume is with the default case of a switch statement, as shown in the following example.".
Is there any other case where __assume can lead to more efficient (or even different) code?
When inside of an if / else, isn't the compiler automatically "assuming" what is already known because of the if condition?
I was unable to find any non-trivial examples that show any of above - I hope someone else could.
Consider the following code, compiled with the /Ox switch:
if (1) {
printf("live code\n");
} else {
printf("dead code\n");
}
The optimizer will optimize away the else. Now consider:
int x = 1;
if (x == 1) {
printf("live code\n");
} else {
printf("dead code\n");
}
The optimizer will once again optimize away the else. Also consider:
int x = 1;
__assume(x != 1);
if (x == 1) {
printf("live code\n");
} else {
printf("dead code\n");
}
The optimizer will optimize away the if this time -- incorrectly so.
To test, build a test program in Release mode (with the /Ox and /Zi options) and look at the generated assembly (Alt+8 in Visual Studio.)
Now consider the above if/else condition being tested in an inline method. In certain contexts, the programmer may know that the inline method is called with a particular value and the optimizer may not have realized this fact. Using __assume at the caller level in the manner illustrated above, just before the inlined method is called, can theoretically help the optimizer.
From Optimization Best Practices (quote from older version):
__assume has been in Visual C++ for
multiple releases, but it has become
much more usable in Visual C++ 2005.
With __assume, a developer can tell
the compiler to make assumptions about
the value of some variable.
For example __assume(a < 5); tells the
optimizer that at that line of code
the variable a is less than 5. Again
this is a promise to the compiler. If
a is actually 6 at this point in the
program then the behavior of the
program after the compiler has
optimized may not be what you would
expect. __assume is most useful prior
to switch statements and/or
conditional expressions.
There are some limitations to
__assume. First, like __restrict, it is only a suggestion, so the compiler
is free to ignore it. Also, __assume
currently works only with variable
inequalities against constants. It
does not propagate symbolic
inequalities, for example, assume(a <
b).
I have an idea about what it is. My question is :-
1.) If i program my code which is amenable to Tail Call optimization(Last statement in a function[recursive function] being a function call only, no other operation there) then do i need to set any optimization level so that compiler does TCO. In what mode of optimization will compiler perform TCO, optimizer for space or time.
2.) How do i find out which all compilers (MSVC, gcc, ARM-RVCT) does support TCO
3.) Assuming some compiler does TCO, we enable it then, What is the way to find out that the compielr has actually done TCO? Will Code size, tell it or Cycles taken to execute it will tell that or both?
-AD
Most compilers support TCO, it is a relatively old technique. As far as how to enable it with a specific compiler, check the documentation for your compilers. gcc will enable the optimization at every optimization level except -O1, I think the specific option for this is -foptimize-sibling-calls. As far as how to tell how/if the compiler is doing TCO, look at the assembler output (gcc -S for example) or disassemble the object code.
Optimization is Compiler specific. Consult the documentation for the various optimization flags for them
You will find that in the Compilers documentation too. If you are curious, you can write a tail recursive function and pass it a big argument, and lookout for a stack-overflow. (tho checking the generated assembler might be a better choice, if you understand the code generated.)
You just use the debugger, and look out the address of function arguments/local variables. If they increase/decrease on each logical frame that the debugger shows (or if it actually only shows one frame, even though you did several calls), you know whether TCO was done or wasn't done.
If you want your compiler to do tail call optimization, just check either
a) the doc of the compiler at which optimization level it will be performed or
b) check the asm, if the function will call itself (you dont even need big asm knowledge to spot the just the symbol of the function again)
If you really really want tail recursion my question would be:
Why dont you perform the tail call removal yourself? It means nothing else than removing the recursion, and if its removable then its not only possible by the compiler on low level but also on algorithmic level by you, that you can programm it direct into your code (it means nothing else than go for a loop instead of a call to yourself).
One way to determine if tail-call is happening is to see if you can force a stack overflow. The following program does not produce a stack overflow using VC++ 2005 Express Edition and, even though its results exceed the capacity of long double rather quickly, you can tell that all of the iterations are being processed when TCO is happening:
/* FibTail.c 0.00 UTF-8 dh:2008-11-23
* --|----1----|----2----|----3----|----4----|----5----|----6----|----*
*
* Demonstrate Fibonacci computation by tail call to see whether it is
* is eliminated through compiler optimization.
*/
#include <stdio.h>
long double fibcycle(long double f0, long double f1, unsigned i)
{ /* accumulate successive fib(n-i) values by tail calls */
if (i == 0) return f1;
return fibcycle(f1, f0+f1, --i);
}
long double fib(unsigned n)
{ /* the basic fib(n) setup and return. */
return fibcycle(1.0, 0.0, n);
}
int main(int argc, char* argv[ ])
{ /* compute some fibs until something breaks */
int i;
printf("\n i fib(i)\n\n");
for (i = 1; i > 0; i+=i)
{ /* Do for powers of 2 until i flips negative
or stack overflow, whichever comes first */
printf("%12d %30.20LG \n", i, fib((unsigned) i) );
}
printf("\n\n");
return 0;
}
Notice, however, that the simplifications to make a pure tail-call in fibcycle is tantamount to figuring out an interative version that doesn't do a tail-call at all (and will work with or without TCO in the compiler.
It might be interesting to experiment in order to see how well the TCO can find optimizations that are not already near-optimal and easily replaced by iterations.