On Mon, Jul 29, 2013 at 5:19 PM, reed kotler <[email protected]> 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. -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
