Bad code generation with -ffast-math

[binji]

Compiling this:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {
  char* endptr;
  --argc, ++argv;
  double total = 0.0;
  for (; argc; argc--, argv++) {
    total += strtod(*argv, &endptr);
  }
  printf("total: %g\n", total);
  return 0;
}

with the command line:

em++ -ffast-math fast_double.c -o fast_double.js

Compiles without error, but generates the erroneous output:

...
case 3: 
 var $3=$argv_addr;
 var $4=HEAP32[(($3)>>2)];
 var $call=_strtod($4, $endptr);
 var $5=$total;
 var $add=((double))+($call);
 $total=$add;
 var $6=$argc_addr;
 var $dec1=((($6)-(1))|0);
 $argc_addr=$dec1;
 var $7=$argv_addr;
 var $incdec_ptr2=(($7+4)|0);
 $argv_addr=$incdec_ptr2;
 label = 2; break;
...

Note the line with (double).

Here is a snippet of the generated bitcode:

for.body:                                         ; preds = %for.cond
  %3 = load i8*** %argv.addr, align 4
  %4 = load i8** %3, align 4
  %call = call double @strtod(i8* %4, i8** %endptr)
  %5 = load double* %total, align 8
  %add = fadd fast double %5, %call
  store double %add, double* %total, align 8
  br label %for.inc

It seems that the line "fadd fast double" is misparsed with fast being the type and double being the variable name.

[kripken]

I can't reproduce the problem. Which version of LLVM are you using?

[binji]

I though that might be the case. I'm using LLVM 3.3, via the pnacl toolchain (pepper.js).

[binji]

Ah, found the documentation here: http://llvm.org/docs/LangRef.html#fast-math-flags.

BTW, I was looking to add a test, but it wasn't clear to me where it should go. Thoughts?

[kripken]

Oh ok, must be a 3.3. thing then.

Since 3.2 won't generate it, let's add a test in tests/cases/ containing LLVM IR with a sample of those fast math modifiers. Supporting them in the compiler should be pretty easy.

[kripken]

incoming branch now passes all the full test suite on 3.3, which is necessary for fixing this.

[kripken]

Fixed on incoming. We just ignore these for now, I am not sure we can implement them because at first guess, they are lower-level than JS can support.

[kripken]

Further investigation shows that it is indeed ok to ignore these from a performance perspective. The LLVM IR optimizer needs them of course, but for purposes of JS we don't. (Native backends might use -ffast-math to do things like change underflow and denormal modes, but those aren't portable.)