Add support for optimization of known library functions

[alivetoolkit]

Add support for optimization of known library functions

[regehr]

Nevermind, I think I see what happened. in the original version the UF returned a true value for isdigit() but 98 isn't a digit, and things went badly after that.

[regehr]

found a few more examples of this pattern, with abs() and labs()

I propose we work around these problems in the obvious, clunky way: by teaching alive about the semantics of these functions. let me know if this seems ok, Nuno.

[nunoplopes]

This is LLVM's SimplifyLibCalls kicking in. Looking at the sheer size of the file, it seems almost impossible to catch up.
Either we can source the spec from somewhere and convert it automatically, then we would end up mostly copying that file, adding little value. I don't know if there are C libs specs out there, but there might be (Deepspec folks?).

A solution might be to simply disable SimplifyLibCalls by tagging everything with the nobuiltin attribute. It's unfortunate, but it seems to be the only realistic approach ATM.
Yet another approach would be to support the top-10 most common functions and only tag the remaining with nobuiltin.
What do you think?

[regehr]

I'll try adding support for a few of these that come up most often, and see how it goes. If this ends up being a stupid approach we can rip out the code and try something different.

[nunoplopes]

The framework to recognize known functions is in: 40333f2
Only 1 function is recognized right now. But it won't generate false-positives like this bug; will simply skip verification.
Now we "just" need to write the spec for the other known functions..