Is C compiler allowed to optimize away unused function arguments?

Question

I know that how arguments are passed to functions is not part of the C standard, and is dependent on the hardware architecture and calling convention.

I also know that an optimizing compiler may automatically inline functions to save on call overhead, and omit code that has no "side effects".

But, I have a question about a specific case:
Lets say there is a non trivial function that can not be inlined or removed, and must be called, that is declared to take no arguments:

int veryImportantFunc() {
    /* do some important stuff */

    return result;
}

But this function is called with arguments:

int result = veryImportantFunc(1, 2, 3);

Is the compiler allowed to call the function without passing these arguments?

Or is there some standard or technical limitation that would prevent this kind of optimization?

Also, what if argument evaluation has side effects:

int counter = 1;
int result = veryImportantFunc(1, ++counter, 3);

Is the compiler obligated to evaluate even without passing the result, or would it be legal to drop the evaluation leaving counter == 1?

And finally, what about extra arguments:

char* anotherFunc(int answer) {
    /* Do stuff */

    return question;
}

if this function is called like this:

char* question = anotherFunc(42, 1);

Can the 1 be dropped by the compiler based on the function declaration?

EDIT: To clarify: I have no intention of writing the kind of code that is in my examples, and I did not find this in any code I am working on.
This question is to learn about how compilers work and what the relevant standards say, so to all of you who advised me to stay away from this kind of code: thank you, but I already know that.

Answer 1

Lets say there is a non trivial function that can not be inlined or removed, and must be called, that is declared to take no arguments:

int veryImportantFunc() {
   /* do some important stuff */

   return result;
}

But this function is called with arguments:

There are two possibilities:

• the function is declared with a "full" prototype such as

  int veryImportantFunc(void);
  

  in this case the call with extra arguments won't compile, as the number of parameters and arguments must match;

• the function is declared as taking an unspecified number of arguments, i.e. the declaration visibile to the call site is

  int veryImportantFunc();
  

  in this case, the call is undefined behavior, as the usage doesn't match the actual function definition.

All the other considerations about optimization aren't particularly interesting, as what you are trying to do is illegal however you look at it.

---

We can stretch this and imagine a situation where passing extra useless arguments is legal, for example a variadic function never using the extra arguments.

In this case, as always, the compiler is free to perform any such optimization as long as the observable behavior isn't impacted, and proceeds "as if" performed according to the C abstract machine.

Given that the details of arguments passing aren't observables¹, the compiler could in line of principle optimize away the argument passing, while the arguments evaluation may still need to be done if it has some observable impact on the program state.

That being said, I have a hard time imagining how such optimization may be implemented in the "classical linking model", but with LTCG it shouldn't be impossible.

---

1. The only observable effects according to the C standard are IO and reads/writes on volatile variables.

Answer 2

To begin with, "declared to take no arguments" is wrong. int veryImportantFunc() is a function accepting any arguments. This is obsolete C style and shouldn't be used. For a function taking no arguments, use (void).

Is the compiler allowed to call the function without passing these arguments?

If the actual function definition does not match the number of arguments, the behavior is undefined.

Also, what if argument evaluation has side effects

Doesn't matter, since arguments are evaluated (in unspecified order) before the function is called.

Is the compiler obligated to evaluate even without passing the result, or would it be legal to drop the evaluation leaving counter == 1?

It will evaluate the arguments and then invoke undefined behavior. Anything can happen.

And finally, what about extra arguments:

Your example won't compile, as it isn't valid C.

Answer 3

The following quotes from the C standard are relevant to your different questions:

6.5.2.2 Function calls
...
2. If the expression that denotes the called function has a type that includes a prototype, the number of arguments shall agree with the number of parameters.
...
4. An argument may be an expression of any complete object type. In preparing for the call to a function, the arguments are evaluated, and each parameter is assigned the value of the corresponding argument.
...
6. If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined. If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (, ...) or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined. If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined.
...
10. There is a sequence point after the evaluations of the function designator and the actual arguments but before the actual call. Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.

Answer 4

Following Pascals theory, it is better to be wrong in believing the compiler can make this optimisation than be right in believing it doesn’t. It serves no purpose to wrongly define a function; if you really must, you can always put a stub in front of it:

int RealSlimShady(void) {
     return Dufus;
}

int MaybeSlimShady(int Mathew, int Mathers) {
    Used(Mathew);
    Used(Mathers);
    return RealSlimShady();
}

Everyone is happy, and if your compiler is worth its salt, there will be 0 code overhead.