uwsampa / accept

an approximate compiler
http://accept.rocks
MIT License
37 stars 14 forks source link

Flow violation errors on std math functions #45

Closed tmoreau89 closed 8 years ago

tmoreau89 commented 8 years ago

Writing the following code:

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

int main(int argc, const char** argv) {

    APPROX double in = atof(argv[1]);
    APPROX double out = sin(in);

    printf("%f\n", out);

    return 0;
}

leads to a precision flow violation error when compiled. However no precision flow violation errors occur when using cos in the place of sin in this example.

Functions where no flow violation errors occur include: cos, exp, log, pow, sqrt, sqrtf

Functions where flow violation errors will occur include: sin, tan, acos, asin, atan, atan2, cosh, sinh, tanh, log10, ceil, fabs, floor, fmod.

The solution is to add an ENDORSE around the arguments of the problematic function, but that means that the function call won't be labeled as approximable which can limit the scope of some approximate optimizations.

sampsyo commented 8 years ago

For context, it looks like our whitelist is somehow breaking down for some of these pure functions but not all. Thanks, T!

jamesbornholt commented 8 years ago

I was randomly poking around. This is because of https://github.com/uwsampa/accept/blob/master/checker/EnerCTypeChecker.cpp#L326, no?

sampsyo commented 8 years ago

Is this real life? I seem to have two whitelists, one of which breaks the other. :cry: How did you know this, @jamesbornholt? Are you an evil wizard?

I'll look more closely at this tomorrow.

sampsyo commented 8 years ago

Ah, I see—this is the type whitelist; I was confused and thinking of the purity whitelist. I feel way less crazy.

Thanks, James!

tmoreau89 commented 8 years ago

Good catch @jamesbornholt!

sampsyo commented 8 years ago

Fixed by expanding the polymorphism whitelist.