sin vs floor : clang bug

Eli Friedman eli.friedman at
Mon Jul 29 18:12:30 PDT 2013

On Mon, Jul 29, 2013 at 5:19 PM, reed kotler <rkotler at> wrote:
> I've finally figured out why sin is working in mips16 fp and floor not.
> This turns out to be a combination clang bug and llvm hack.
> If you compile a call to "sin" and a call to "floor", the attributes are
> different.
> For floor they are { nounwind readnone }.
> For sin they are { nounwind } .
> This makes a difference in llvm because they use this information to figure
> out if something
> is an intrinsic in SelectionDAGBuilder::visitUnaryFloatCall (seems like this
> is the wrong way
> to do this; there should be a separate attribute for this).
> Sin ends up failing this test in the beginning of the function.
>   // Sanity check that it really is a unary floating-point call.
>   if (I.getNumArgOperands() != 1 ||
>       !I.getArgOperand(0)->getType()->isFloatingPointTy() ||
>       I.getType() != I.getArgOperand(0)->getType() ||
>       !I.onlyReadsMemory())
>     return false;
> Because onlyReadsMemory() becomes false.
> This bug makes Sin work for Mips16 because the proper signature for the
> external exists at that time and the call can be emitted.
> When this bug is fixed, then sin will also fail for mips16; however I have a
> way to deal with this problem so it's not an issue for me but I wanted to
> understand the root cause of the problem.

The clang "bug" isn't actually a bug; we do this intentionally so
-fmath-errno works.


More information about the cfe-commits mailing list