[cfe-dev] missing return statement for non-void functions in C++

[Hans Wennborg]

On Wed, Jul 29, 2015 at 7:37 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "David Blaikie" <dblaikie at gmail.com>
>> To: "James Molloy" <james at jamesmolloy.co.uk>
>> Cc: "Marshall Clow" <mclow.lists at gmail.com>, "cfe-dev Developers" <cfe-dev at cs.uiuc.edu>
>> Sent: Wednesday, July 29, 2015 9:15:09 AM
>> Subject: Re: [cfe-dev] missing return statement for non-void functions in C++
>>
>>
>> On Jul 29, 2015 7:06 AM, "James Molloy" < james at jamesmolloy.co.uk >
>> wrote:
>> >
>> > Hi,
>> >
>> > If we're going to emit a trap instruction (and thus create a broken
>> > binary), why don't we error instead?
>>
>> We warn, can't error, because it may be dynamically unreached, in
>> which case the program is valid and we can't reject it.
>
> I think this also explains why this is useful for optimization.
>
>  1. It is a code-size optimization
>  2. By eliminating unreachable control flow, we can remove branches and tests that are not actual necessary
>
> int foo(int x) {
>   if (x > 5) return 2*x;
>   else if (x < 2) return 3 - x;
> }

We exploit this for switches too:

unsigned f(color c) {
  switch(c) {
    case red:     return 0xff0000;
    case green:   return 0x00ff00;
    case blue:    return 0x0000ff;
    case magenta: return 0xff00ff;
  }
}

becomes

movslq %edi, %rax
movl .Lswitch.table(,%rax,4), %eax
retq

i.e. the range check for the lookup table is omitted. (We don't do
this for jump tables yet, but it's on my todo list).