[IR] Add llvm.tan.* intrinsic

[junaire]

Summary

This patch adds llvm.tan.* intrinsic and corresponding DAG nodes support
for X86 target.

The motivation of the patch is that even if it's uncommon to see tan in
real code, but it will make things a lot easier to do optimizations and
folds if we could have uniformity of trig intrinsics.

Related issue: https://github.com/llvm/llvm-project/issues/34950

Signed-off-by: Jun Zhang <[e-mail]>

[RKSimon]

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

124

We probably want to add STRICT_FTAN at the same time.

llvm/test/CodeGen/X86/llvm.tan.ll

39

It'd be better to put these in the existing test files with other libm calls - fp128-libcalls.ll etc. - I'm not sure how thorough our existing tests are for these though - grepping for sin.f32 doesn't bring up much for instance.

[junaire]

1. Add STRICT_TAN
2. Add more tests

[junaire]

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

124

I have to admit I know nothing about it and I just simply grep STRICT_FSIN and add corresponding cases. I'm confused about where it comes from since there's no occurrence in SelectionDAGBuilder.cpp.

It'll be helpful if you can elaborate a bit about how these things work under the hood! :)

llvm/test/CodeGen/X86/llvm.tan.ll

39

I'm uncertain about what's the right way to go. It seems the tests for these trig intrinsics are pretty messy and we're lacking test coverage for the X86 target. I created this new file since I saw a test in llvm/test/CodeGen/AMDGPU/llvm.sin.ll.

I'd propose just leaving it as is, but if you insist I can move them (Then what about llvm.tan.f32 f64 ?)

[nikic]

Adding some people who might have opinions on more FP intrinsics.

[jdoerfert]

I voiced this before and while I will repeat it here I won't block this patch all by myself:

This is a bad idea.

We are playing whack-a-mole and assuming we don't want to commit to all of them (math intrinsics), this is always going to be a source of "weird behavior", to say the least.
Even if we had all of them there are still unsolved problems as soon as you leave the space of systems with a libm that is linked in late since not all intrinsics lower to target instructions but rather libm calls.

What we should do is to remove all math intrinsics and instead work on the math functions themselves, as we do with other library functions (malloc, free, ...).
A math intrinsic is literally a regular call to the corresponding math function with a no_errno flag attached to it (and the type encoded in the name):
We probably even have all the attributes today to express that:

declare double @tan(double) memory(readonly)

[Not to mention that this makes tan, which is represented as target independent math intrinsic, special only for X86...]

Now there have been arguments for intrinsics, e.g., lib call matching is bad. I don't disagree, but we can fix that.
It was also raised that we treat intrinsics as cheap and calls as expensive in heuristics, though, that is just not right to begin with.
A math call is the same if we call the math function as part of the lowering anyway, no matter if it was a call or intrinsic call in the IR.
That said, we can make smarter choices for heuristics fairly easily, e.g., a readnone call is probably not going to be too expensive.

All that said, I think we should recognize math functions and annotate them, but just not as intrinsics. Maybe something like this:

define double @tan(double) libm(tan,double))
define float @tanf(float) libm(tan,float))
...

[pengfei]

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

124

The strict nodes come from constrained intrinsics emitted by the FE under strict mode, see D70256

[craig.topper]

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

124

They aren't directly referenced in SelectionDAGBuilder.cpp because they go through this code

  case Intrinsic::INTRINSIC:                                                     
#include "llvm/IR/ConstrainedOps.def"                                            
    visitConstrainedFPIntrinsic(cast<ConstrainedFPIntrinsic>(I));                
    return;

[junaire]

In D146905#4222696, @jdoerfert wrote:

I voiced this before and while I will repeat it here I won't block this patch all by myself:

This is a bad idea.

We are playing whack-a-mole and assuming we don't want to commit to all of them (math intrinsics), this is always going to be a source of "weird behavior", to say the least.
Even if we had all of them there are still unsolved problems as soon as you leave the space of systems with a libm that is linked in late since not all intrinsics lower to target instructions but rather libm calls.

What we should do is to remove all math intrinsics and instead work on the math functions themselves, as we do with other library functions (malloc, free, ...).
A math intrinsic is literally a regular call to the corresponding math function with a no_errno flag attached to it (and the type encoded in the name):
We probably even have all the attributes today to express that:

declare double @tan(double) memory(readonly)

[Not to mention that this makes tan, which is represented as target independent math intrinsic, special only for X86...]

Now there have been arguments for intrinsics, e.g., lib call matching is bad. I don't disagree, but we can fix that.
It was also raised that we treat intrinsics as cheap and calls as expensive in heuristics, though, that is just not right to begin with.
A math call is the same if we call the math function as part of the lowering anyway, no matter if it was a call or intrinsic call in the IR.
That said, we can make smarter choices for heuristics fairly easily, e.g., a readnone call is probably not going to be too expensive.

All that said, I think we should recognize math functions and annotate them, but just not as intrinsics. Maybe something like this:

define double @tan(double) libm(tan,double))
define float @tanf(float) libm(tan,float))
...

Hi @jdoerfert, thanks for the heads up. I've read the whole thread you linked and believe what you proposed is reasonable. However, it looks like there's no obvious consensus so far in the community, and everything is just in discussion? The one thing I agree with is that the whole thing is a mess. I'd suggest you start an RFC about how we handle math intrinsic and libcall matchings. But before that, the best choice for now I think is to keep those trig calls consistent so it's easier to do folds in the middle end, and that's the primary reason for me to create the patch.

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

124

Thank @pengfei & @craig.topper for the explanation, that works for me!

[craig.topper]

In D146905#4222910, @junaire wrote:

In D146905#4222696, @jdoerfert wrote:

I voiced this before and while I will repeat it here I won't block this patch all by myself:

This is a bad idea.

We are playing whack-a-mole and assuming we don't want to commit to all of them (math intrinsics), this is always going to be a source of "weird behavior", to say the least.
Even if we had all of them there are still unsolved problems as soon as you leave the space of systems with a libm that is linked in late since not all intrinsics lower to target instructions but rather libm calls.

What we should do is to remove all math intrinsics and instead work on the math functions themselves, as we do with other library functions (malloc, free, ...).
A math intrinsic is literally a regular call to the corresponding math function with a no_errno flag attached to it (and the type encoded in the name):
We probably even have all the attributes today to express that:

declare double @tan(double) memory(readonly)

[Not to mention that this makes tan, which is represented as target independent math intrinsic, special only for X86...]

Now there have been arguments for intrinsics, e.g., lib call matching is bad. I don't disagree, but we can fix that.
It was also raised that we treat intrinsics as cheap and calls as expensive in heuristics, though, that is just not right to begin with.
A math call is the same if we call the math function as part of the lowering anyway, no matter if it was a call or intrinsic call in the IR.
That said, we can make smarter choices for heuristics fairly easily, e.g., a readnone call is probably not going to be too expensive.

All that said, I think we should recognize math functions and annotate them, but just not as intrinsics. Maybe something like this:

define double @tan(double) libm(tan,double))
define float @tanf(float) libm(tan,float))
...

Hi @jdoerfert, thanks for the heads up. I've read the whole thread you linked and believe what you proposed is reasonable. However, it looks like there's no obvious consensus so far in the community, and everything is just in discussion? The one thing I agree with is that the whole thing is a mess. I'd suggest you start an RFC about how we handle math intrinsic and libcall matchings. But before that, the best choice for now I think is to keep those trig calls consistent so it's easier to do folds in the middle end, and that's the primary reason for me to create the patch.

We already do math folds in the middle end. See LibCallSimplifier::optimizeFloatingPointLibCall. We even recognize tan there. Adding an intrinsic would disable the existing optimizations for tan.

[junaire]

In D146905#4223155, @craig.topper wrote:

In D146905#4222910, @junaire wrote:

In D146905#4222696, @jdoerfert wrote:

I voiced this before and while I will repeat it here I won't block this patch all by myself:

This is a bad idea.

We are playing whack-a-mole and assuming we don't want to commit to all of them (math intrinsics), this is always going to be a source of "weird behavior", to say the least.
Even if we had all of them there are still unsolved problems as soon as you leave the space of systems with a libm that is linked in late since not all intrinsics lower to target instructions but rather libm calls.

What we should do is to remove all math intrinsics and instead work on the math functions themselves, as we do with other library functions (malloc, free, ...).
A math intrinsic is literally a regular call to the corresponding math function with a no_errno flag attached to it (and the type encoded in the name):
We probably even have all the attributes today to express that:

declare double @tan(double) memory(readonly)

[Not to mention that this makes tan, which is represented as target independent math intrinsic, special only for X86...]

Now there have been arguments for intrinsics, e.g., lib call matching is bad. I don't disagree, but we can fix that.
It was also raised that we treat intrinsics as cheap and calls as expensive in heuristics, though, that is just not right to begin with.
A math call is the same if we call the math function as part of the lowering anyway, no matter if it was a call or intrinsic call in the IR.
That said, we can make smarter choices for heuristics fairly easily, e.g., a readnone call is probably not going to be too expensive.

All that said, I think we should recognize math functions and annotate them, but just not as intrinsics. Maybe something like this:

define double @tan(double) libm(tan,double))
define float @tanf(float) libm(tan,float))
...

Hi @jdoerfert, thanks for the heads up. I've read the whole thread you linked and believe what you proposed is reasonable. However, it looks like there's no obvious consensus so far in the community, and everything is just in discussion? The one thing I agree with is that the whole thing is a mess. I'd suggest you start an RFC about how we handle math intrinsic and libcall matchings. But before that, the best choice for now I think is to keep those trig calls consistent so it's easier to do folds in the middle end, and that's the primary reason for me to create the patch.

We already do math folds in the middle end. See LibCallSimplifier::optimizeFloatingPointLibCall. We even recognize tan there. Adding an intrinsic would disable the existing optimizations for tan.

Yes and no. I mean those 10th-grade trigonometrical identities like https://godbolt.org/z/nxvPe5en5. These should be handled in InstCombine. Yes, you can argue that it's unnecessary to add an intrinsic to do these folds but obviously, it will make things a lot easier and more clear if we have consistent intrinsics. In fact, there's a patch long ago trying to fix the problem: https://reviews.llvm.org/D41283

[craig.topper]

In D146905#4223192, @junaire wrote:

In D146905#4223155, @craig.topper wrote:

In D146905#4222910, @junaire wrote:

In D146905#4222696, @jdoerfert wrote:

I voiced this before and while I will repeat it here I won't block this patch all by myself:

This is a bad idea.

We are playing whack-a-mole and assuming we don't want to commit to all of them (math intrinsics), this is always going to be a source of "weird behavior", to say the least.
Even if we had all of them there are still unsolved problems as soon as you leave the space of systems with a libm that is linked in late since not all intrinsics lower to target instructions but rather libm calls.

What we should do is to remove all math intrinsics and instead work on the math functions themselves, as we do with other library functions (malloc, free, ...).
A math intrinsic is literally a regular call to the corresponding math function with a no_errno flag attached to it (and the type encoded in the name):
We probably even have all the attributes today to express that:

declare double @tan(double) memory(readonly)

[Not to mention that this makes tan, which is represented as target independent math intrinsic, special only for X86...]

Now there have been arguments for intrinsics, e.g., lib call matching is bad. I don't disagree, but we can fix that.
It was also raised that we treat intrinsics as cheap and calls as expensive in heuristics, though, that is just not right to begin with.
A math call is the same if we call the math function as part of the lowering anyway, no matter if it was a call or intrinsic call in the IR.
That said, we can make smarter choices for heuristics fairly easily, e.g., a readnone call is probably not going to be too expensive.

All that said, I think we should recognize math functions and annotate them, but just not as intrinsics. Maybe something like this:

define double @tan(double) libm(tan,double))
define float @tanf(float) libm(tan,float))
...

Hi @jdoerfert, thanks for the heads up. I've read the whole thread you linked and believe what you proposed is reasonable. However, it looks like there's no obvious consensus so far in the community, and everything is just in discussion? The one thing I agree with is that the whole thing is a mess. I'd suggest you start an RFC about how we handle math intrinsic and libcall matchings. But before that, the best choice for now I think is to keep those trig calls consistent so it's easier to do folds in the middle end, and that's the primary reason for me to create the patch.

We already do math folds in the middle end. See LibCallSimplifier::optimizeFloatingPointLibCall. We even recognize tan there. Adding an intrinsic would disable the existing optimizations for tan.

Yes and no. I mean those 10th-grade trigonometrical identities like https://godbolt.org/z/nxvPe5en5. These should be handled in InstCombine. Yes, you can argue that it's unnecessary to add an intrinsic to do these folds but obviously, it will make things a lot easier and more clear if we have consistent intrinsics. In fact, there's a patch long ago trying to fix the problem: https://reviews.llvm.org/D41283

LibCallSimplifier::optimizeFloatingPointLibCall should be called during InstCombine via the use of LibCallSimplifier in InstCombinerImpl::tryOptimizeCall.

Adding an intrinsic for tan will require adding intrinsic versions of the existing tan optimizations in optimizeFloatingPointLibCall to avoid regressions there.

Need to add it to llvm/include/llvm/Analysis/VecFuncs.def so the vectorizer knows it can vectorize it to vector math library. Weirdly some parts of that file think llvm.tan and some other intrinsics already exists.

I suppose llvm.tan should also be added to llvm::isTriviallyVectorizable in VectorUtils.cpp.

[craig.topper]

Is there a corresponding patch for the clang part?

[craig.topper]

llvm/lib/Target/X86/X86ISelLowering.cpp

650

We should default this to Expand in llvm/lib/CodeGen/TargetLoweringBase.cpp like we do for ISD::CBRT. That will be needed to properly support other targets than X86.

650

Oops ISD::FCBRT

[junaire]

Address comments

[junaire]

In D146905#4225435, @craig.topper wrote:

Is there a corresponding patch for the clang part?

Not yet. But I'll create one later.

LibCallSimplifier::optimizeFloatingPointLibCall should be called during InstCombine via the use of LibCallSimplifier in InstCombinerImpl::tryOptimizeCall.
Adding an intrinsic for tan will require adding intrinsic versions of the existing tan optimizations in optimizeFloatingPointLibCall to avoid regressions there.

Ughh, does it should be handled in InstCombinerImpl::visitCallInst? Looks like if it's an intrinsic, it will not take the code path? (https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp#L1311-L1312)

Need to add it to llvm/include/llvm/Analysis/VecFuncs.def so the vectorizer knows it can vectorize it to vector math library. Weirdly some parts of that file think llvm.tan and some other intrinsics already exists.
I suppose llvm.tan should also be added to llvm::isTriviallyVectorizable in VectorUtils.cpp.

Done.

[kpn]

I don't see any tests for a constrained/STRICT tan. We do have tests for constrained sin and cos so tan tests where sin and cos are tested is probably appropriate.

llvm/docs/LangRef.rst

14560

If you are adding a constrained/STRICT tan then you need to document it.

[craig.topper]

FWIW, I agree with @jdoerfert that we should do this on the scalar libcall. The amount of code touched here to make the intended combine simpler doesn't seem justified.

[junaire]

Alright, thanks everyone for the comments. I think I'll just abandon the patch and try to do folds in the libcall directly.

llvm/docs/LangRef.rst

 """"""""""
 
 Return the same value as a corresponding libm '``cos``' function but without
 trapping or setting ``errno``.
 
 When specified with the fast-math-flag 'afn', the result may be approximated
 using a less accurate calculation.
 
+
+'``llvm.tan.*``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+This is an overloaded intrinsic. You can use ``llvm.tan`` on any
+floating-point or vector of floating-point type. Not all targets support
+all types however.
+
+::
+
+      declare float     @llvm.tan.f32(float  %Val)
+      declare double    @llvm.tan.f64(double %Val)
+      declare x86_fp80  @llvm.tan.f80(x86_fp80  %Val)
+      declare fp128     @llvm.tan.f128(fp128 %Val)
+      declare ppc_fp128 @llvm.tan.ppcf128(ppc_fp128  %Val)
+
+Overview:
+"""""""""
+
+The '``llvm.tan.*``' intrinsics return the tangent of the operand.
+
+Arguments:
+""""""""""
+
+The argument and return value are floating-point numbers of the same type.
+
+Semantics:
+""""""""""
+
+Return the same value as a corresponding libm '``tan``' function but without
+trapping or setting ``errno``.
+
+When specified with the fast-math-flag 'afn', the result may be approximated
+using a less accurate calculation.
+
 '``llvm.pow.*``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Syntax:
 """""""
 
 This is an overloaded intrinsic. You can use ``llvm.pow`` on any
 floating-point or vector of floating-point type. Not all targets support

llvm/include/llvm/CodeGen/ISDOpcodes.h

enum NodeType {
   /// FPOWI, the result is undefined if if the integer operand doesn't fit into
   /// sizeof(int).
   FNEG,
   FABS,
   FSQRT,
   FCBRT,
   FSIN,
   FCOS,
+  FTAN,
   FPOWI,
   FPOW,
   FLOG,
   FLOG2,
   FLOG10,
   FEXP,
   FEXP2,
   FCEIL,

llvm/include/llvm/IR/Intrinsics.td

let IntrProperties = [IntrNoMem, IntrSpeculatable, IntrWillReturn] in {
 
   // These functions do not read memory, but are sensitive to the
   // rounding mode. LLVM purposely does not model changes to the FP
   // environment so they can be treated as readnone.
   def int_sqrt : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_powi : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, llvm_anyint_ty]>;
   def int_sin  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_cos  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
+  def int_tan  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_pow  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty],
                            [LLVMMatchType<0>, LLVMMatchType<0>]>;
   def int_log  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_log10: DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_log2 : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_exp  : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_exp2 : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;
   def int_fabs : DefaultAttrsIntrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>]>;

llvm/include/llvm/IR/RuntimeLibcalls.def

 HANDLE_LIBCALL(SIN_F80, "sinl")
 HANDLE_LIBCALL(SIN_F128, "sinl")
 HANDLE_LIBCALL(SIN_PPCF128, "sinl")
 HANDLE_LIBCALL(COS_F32, "cosf")
 HANDLE_LIBCALL(COS_F64, "cos")
 HANDLE_LIBCALL(COS_F80, "cosl")
 HANDLE_LIBCALL(COS_F128, "cosl")
 HANDLE_LIBCALL(COS_PPCF128, "cosl")
+HANDLE_LIBCALL(TAN_F32, "tanf")
+HANDLE_LIBCALL(TAN_F64, "tan")
+HANDLE_LIBCALL(TAN_F80, "tanl")
+HANDLE_LIBCALL(TAN_F128, "tanl")
+HANDLE_LIBCALL(TAN_PPCF128, "tanl")
 HANDLE_LIBCALL(SINCOS_F32, nullptr)
 HANDLE_LIBCALL(SINCOS_F64, nullptr)
 HANDLE_LIBCALL(SINCOS_F80, nullptr)
 HANDLE_LIBCALL(SINCOS_F128, nullptr)
 HANDLE_LIBCALL(SINCOS_PPCF128, nullptr)
 HANDLE_LIBCALL(SINCOS_STRET_F32, nullptr)
 HANDLE_LIBCALL(SINCOS_STRET_F64, nullptr)
 HANDLE_LIBCALL(POW_F32, "powf")

llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp

case ISD::STRICT_FCOS:
     ExpandFPLibCall(Node, RTLIB::COS_F32, RTLIB::COS_F64,
                     RTLIB::COS_F80, RTLIB::COS_F128,
                     RTLIB::COS_PPCF128, Results);
     break;
   case ISD::FSINCOS:
     // Expand into sincos libcall.
     ExpandSinCosLibCall(Node, Results);
     break;
+  case ISD::FTAN:
+    ExpandFPLibCall(Node, RTLIB::TAN_F32, RTLIB::TAN_F64,
+                    RTLIB::TAN_F80, RTLIB::TAN_F128,
+                    RTLIB::TAN_PPCF128, Results);
+    break;
   case ISD::FLOG:
   case ISD::STRICT_FLOG:
     ExpandFPLibCall(Node, RTLIB::LOG_F32, RTLIB::LOG_F64, RTLIB::LOG_F80,
                     RTLIB::LOG_F128, RTLIB::LOG_PPCF128, Results);
     break;
   case ISD::FLOG2:
   case ISD::STRICT_FLOG2:
     ExpandFPLibCall(Node, RTLIB::LOG2_F32, RTLIB::LOG2_F64, RTLIB::LOG2_F80,

llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp

#endif
     case ISD::STRICT_FRINT:
     case ISD::FRINT:       R = SoftenFloatRes_FRINT(N); break;
     case ISD::STRICT_FROUND:
     case ISD::FROUND:      R = SoftenFloatRes_FROUND(N); break;
     case ISD::STRICT_FROUNDEVEN:
     case ISD::FROUNDEVEN:  R = SoftenFloatRes_FROUNDEVEN(N); break;
     case ISD::STRICT_FSIN:
     case ISD::FSIN:        R = SoftenFloatRes_FSIN(N); break;
+    case ISD::FTAN:        R = SoftenFloatRes_FTAN(N); break;
     case ISD::STRICT_FSQRT:
     case ISD::FSQRT:       R = SoftenFloatRes_FSQRT(N); break;
     case ISD::STRICT_FSUB:
     case ISD::FSUB:        R = SoftenFloatRes_FSUB(N); break;
     case ISD::STRICT_FTRUNC:
     case ISD::FTRUNC:      R = SoftenFloatRes_FTRUNC(N); break;
     case ISD::LOAD:        R = SoftenFloatRes_LOAD(N); break;
     case ISD::ATOMIC_SWAP: R = BitcastToInt_ATOMIC_SWAP(N); break;
SDValue DAGTypeLegalizer::SoftenFloatRes_FCOS(SDNode *N) {
   return SoftenFloatRes_Unary(N, GetFPLibCall(N->getValueType(0),
                                               RTLIB::COS_F32,
                                               RTLIB::COS_F64,
                                               RTLIB::COS_F80,
                                               RTLIB::COS_F128,
                                               RTLIB::COS_PPCF128));
 }
 
+SDValue DAGTypeLegalizer::SoftenFloatRes_FTAN(SDNode *N) {
+  return SoftenFloatRes_Unary(N, GetFPLibCall(N->getValueType(0),
+                                              RTLIB::TAN_F32,
+                                              RTLIB::TAN_F64,
+                                              RTLIB::TAN_F80,
+                                              RTLIB::TAN_F128,
+                                              RTLIB::TAN_PPCF128));
+}
+
 SDValue DAGTypeLegalizer::SoftenFloatRes_FDIV(SDNode *N) {
   return SoftenFloatRes_Binary(N, GetFPLibCall(N->getValueType(0),
                                                RTLIB::DIV_F32,
                                                RTLIB::DIV_F64,
                                                RTLIB::DIV_F80,
                                                RTLIB::DIV_F128,
                                                RTLIB::DIV_PPCF128));
 }
#endif
   case ISD::STRICT_FRINT:
   case ISD::FRINT:      ExpandFloatRes_FRINT(N, Lo, Hi); break;
   case ISD::STRICT_FROUND:
   case ISD::FROUND:     ExpandFloatRes_FROUND(N, Lo, Hi); break;
   case ISD::STRICT_FROUNDEVEN:
   case ISD::FROUNDEVEN: ExpandFloatRes_FROUNDEVEN(N, Lo, Hi); break;
   case ISD::STRICT_FSIN:
   case ISD::FSIN:       ExpandFloatRes_FSIN(N, Lo, Hi); break;
+  case ISD::FTAN:       ExpandFloatRes_FTAN(N, Lo, Hi); break;
   case ISD::STRICT_FSQRT:
   case ISD::FSQRT:      ExpandFloatRes_FSQRT(N, Lo, Hi); break;
   case ISD::STRICT_FSUB:
   case ISD::FSUB:       ExpandFloatRes_FSUB(N, Lo, Hi); break;
   case ISD::STRICT_FTRUNC:
   case ISD::FTRUNC:     ExpandFloatRes_FTRUNC(N, Lo, Hi); break;
   case ISD::LOAD:       ExpandFloatRes_LOAD(N, Lo, Hi); break;
   case ISD::STRICT_SINT_TO_FP:

 void DAGTypeLegalizer::ExpandFloatRes_FSIN(SDNode *N,
                                            SDValue &Lo, SDValue &Hi) {
   ExpandFloatRes_Unary(N, GetFPLibCall(N->getValueType(0),
                                        RTLIB::SIN_F32, RTLIB::SIN_F64,
                                        RTLIB::SIN_F80, RTLIB::SIN_F128,
                                        RTLIB::SIN_PPCF128), Lo, Hi);
 }
 
+void DAGTypeLegalizer::ExpandFloatRes_FTAN(SDNode *N,
+                                           SDValue &Lo, SDValue &Hi) {
+  ExpandFloatRes_Unary(N, GetFPLibCall(N->getValueType(0),
+                                       RTLIB::TAN_F32, RTLIB::TAN_F64,
+                                       RTLIB::TAN_F80, RTLIB::TAN_F128,
+                                       RTLIB::TAN_PPCF128), Lo, Hi);
+}
+
 void DAGTypeLegalizer::ExpandFloatRes_FSQRT(SDNode *N,
                                             SDValue &Lo, SDValue &Hi) {
   ExpandFloatRes_Unary(N, GetFPLibCall(N->getValueType(0),
                                        RTLIB::SQRT_F32, RTLIB::SQRT_F64,
                                        RTLIB::SQRT_F80, RTLIB::SQRT_F128,
                                        RTLIB::SQRT_PPCF128), Lo, Hi);
 }
 
#endif
     case ISD::FLOG10:
     case ISD::FNEARBYINT:
     case ISD::FNEG:
     case ISD::FRINT:
     case ISD::FROUND:
     case ISD::FROUNDEVEN:
     case ISD::FSIN:
     case ISD::FSQRT:
+    case ISD::FTAN:
     case ISD::FTRUNC:
     case ISD::FCANONICALIZE: R = PromoteFloatRes_UnaryOp(N); break;
 
     // Binary FP Operations
     case ISD::FADD:
     case ISD::FDIV:
     case ISD::FMAXIMUM:
     case ISD::FMINIMUM:
#endif
   case ISD::FNEG:
   case ISD::FREEZE:
   case ISD::FRINT:
   case ISD::FROUND:
   case ISD::FROUNDEVEN:
   case ISD::FSIN:
   case ISD::FSQRT:
   case ISD::FTRUNC:
+  case ISD::FTAN:
   case ISD::FCANONICALIZE: R = SoftPromoteHalfRes_UnaryOp(N); break;
 
   // Binary FP Operations
   case ISD::FADD:
   case ISD::FDIV:
   case ISD::FMAXIMUM:
   case ISD::FMINIMUM:
   case ISD::FMAXNUM:

llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.h

private:
   SDValue SoftenFloatRes_FABS(SDNode *N);
   SDValue SoftenFloatRes_FMINNUM(SDNode *N);
   SDValue SoftenFloatRes_FMAXNUM(SDNode *N);
   SDValue SoftenFloatRes_FADD(SDNode *N);
   SDValue SoftenFloatRes_FCBRT(SDNode *N);
   SDValue SoftenFloatRes_FCEIL(SDNode *N);
   SDValue SoftenFloatRes_FCOPYSIGN(SDNode *N);
   SDValue SoftenFloatRes_FCOS(SDNode *N);
+  SDValue SoftenFloatRes_FTAN(SDNode *N);
   SDValue SoftenFloatRes_FDIV(SDNode *N);
   SDValue SoftenFloatRes_FEXP(SDNode *N);
   SDValue SoftenFloatRes_FEXP2(SDNode *N);
   SDValue SoftenFloatRes_FFLOOR(SDNode *N);
   SDValue SoftenFloatRes_FLOG(SDNode *N);
   SDValue SoftenFloatRes_FLOG2(SDNode *N);
   SDValue SoftenFloatRes_FLOG10(SDNode *N);
   SDValue SoftenFloatRes_FMA(SDNode *N);
private:
   void ExpandFloatRes_FPOW      (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FPOWI     (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FREEZE    (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FREM      (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FRINT     (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FROUND    (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FROUNDEVEN(SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FSIN      (SDNode *N, SDValue &Lo, SDValue &Hi);
+  void ExpandFloatRes_FTAN      (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FSQRT     (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FSUB      (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_FTRUNC    (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_LOAD      (SDNode *N, SDValue &Lo, SDValue &Hi);
   void ExpandFloatRes_XINT_TO_FP(SDNode *N, SDValue &Lo, SDValue &Hi);
 
   // Float Operand Expansion.
   bool ExpandFloatOperand(SDNode *N, unsigned OpNo);

llvm/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

#include "llvm/IR/ConstrainedOps.def"
   case ISD::FMINNUM_IEEE:
   case ISD::FMAXNUM_IEEE:
   case ISD::FMINIMUM:
   case ISD::FMAXIMUM:
   case ISD::FCOPYSIGN:
   case ISD::FSQRT:
   case ISD::FSIN:
   case ISD::FCOS:
+  case ISD::FTAN:
   case ISD::FPOWI:
   case ISD::FPOW:
   case ISD::FLOG:
   case ISD::FLOG2:
   case ISD::FLOG10:
   case ISD::FEXP:
   case ISD::FEXP2:
   case ISD::FCEIL:

llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp

#endif
   case ISD::ARITH_FENCE:
   case ISD::FP_EXTEND:
   case ISD::FP_TO_SINT:
   case ISD::FP_TO_UINT:
   case ISD::FRINT:
   case ISD::FROUND:
   case ISD::FROUNDEVEN:
   case ISD::FSIN:
+  case ISD::FTAN:
   case ISD::FSQRT:
   case ISD::FTRUNC:
   case ISD::SIGN_EXTEND:
   case ISD::SINT_TO_FP:
   case ISD::TRUNCATE:
   case ISD::UINT_TO_FP:
   case ISD::ZERO_EXTEND:
   case ISD::FCANONICALIZE:
#endif
   case ISD::VP_FP_TO_UINT:
   case ISD::FRINT:
   case ISD::VP_FRINT:
   case ISD::FROUND:
   case ISD::VP_FROUND:
   case ISD::FROUNDEVEN:
   case ISD::VP_FROUNDEVEN:
   case ISD::FSIN:
+  case ISD::FTAN:
   case ISD::FSQRT: case ISD::VP_SQRT:
   case ISD::FTRUNC:
   case ISD::VP_FROUNDTOZERO:
   case ISD::SINT_TO_FP:
   case ISD::VP_SINT_TO_FP:
   case ISD::TRUNCATE:
   case ISD::VP_TRUNCATE:
   case ISD::UINT_TO_FP:
#include "llvm/IR/ConstrainedOps.def"
   case ISD::FLOG:
   case ISD::FLOG10:
   case ISD::FLOG2:
   case ISD::FNEARBYINT:
   case ISD::FRINT:
   case ISD::FROUND:
   case ISD::FROUNDEVEN:
   case ISD::FSIN:
+  case ISD::FTAN:
   case ISD::FSQRT:
   case ISD::FTRUNC:
     if (unrollExpandedOp())
       break;
     // If the target has custom/legal support for the scalar FP intrinsic ops
     // (they are probably not destined to become libcalls), then widen those
     // like any other unary ops.
     [[fallthrough]];

llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp

bool SelectionDAG::isKnownNeverNaN(SDValue Op, bool SNaN, unsigned Depth) const {
   switch (Opcode) {
   case ISD::FADD:
   case ISD::FSUB:
   case ISD::FMUL:
   case ISD::FDIV:
   case ISD::FREM:
   case ISD::FSIN:
   case ISD::FCOS:
+  case ISD::FTAN:
   case ISD::FMA:
   case ISD::FMAD: {
     if (SNaN)
       return true;
     // TODO: Need isKnownNeverInfinity
     return false;
   }
   case ISD::FCANONICALIZE:

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

void SelectionDAGBuilder::visitIntrinsicCall(const CallInst &I,
   case Intrinsic::pow:
     setValue(&I, expandPow(sdl, getValue(I.getArgOperand(0)),
                            getValue(I.getArgOperand(1)), DAG, TLI, Flags));
     return;
   case Intrinsic::sqrt:
   case Intrinsic::fabs:
   case Intrinsic::sin:
   case Intrinsic::cos:
+  case Intrinsic::tan:
   case Intrinsic::floor:
   case Intrinsic::ceil:
   case Intrinsic::trunc:
   case Intrinsic::rint:
   case Intrinsic::nearbyint:
   case Intrinsic::round:
   case Intrinsic::roundeven:
   case Intrinsic::canonicalize: {
     unsigned Opcode;
     switch (Intrinsic) {
     default: llvm_unreachable("Impossible intrinsic");  // Can't reach here.
     case Intrinsic::sqrt:      Opcode = ISD::FSQRT;      break;
     case Intrinsic::fabs:      Opcode = ISD::FABS;       break;
     case Intrinsic::sin:       Opcode = ISD::FSIN;       break;
     case Intrinsic::cos:       Opcode = ISD::FCOS;       break;
+    case Intrinsic::tan:       Opcode = ISD::FTAN;       break;
     case Intrinsic::floor:     Opcode = ISD::FFLOOR;     break;
     case Intrinsic::ceil:      Opcode = ISD::FCEIL;      break;
     case Intrinsic::trunc:     Opcode = ISD::FTRUNC;     break;
     case Intrinsic::rint:      Opcode = ISD::FRINT;      break;
     case Intrinsic::nearbyint: Opcode = ISD::FNEARBYINT; break;
     case Intrinsic::round:     Opcode = ISD::FROUND;     break;
     case Intrinsic::roundeven: Opcode = ISD::FROUNDEVEN; break;
     case Intrinsic::canonicalize: Opcode = ISD::FCANONICALIZE; break;
if (!I.isNoBuiltin() && !I.isStrictFP() && !F->hasLocalLinkage() &&
           return;
         break;
       case LibFunc_cos:
       case LibFunc_cosf:
       case LibFunc_cosl:
         if (visitUnaryFloatCall(I, ISD::FCOS))
           return;
         break;
+      case LibFunc_tan:
+      case LibFunc_tanf:
+      case LibFunc_tanl:
+        if (visitUnaryFloatCall(I, ISD::FTAN))
+          return;
+        break;
       case LibFunc_sqrt:
       case LibFunc_sqrtf:
       case LibFunc_sqrtl:
       case LibFunc_sqrt_finite:
       case LibFunc_sqrtf_finite:
       case LibFunc_sqrtl_finite:
         if (visitUnaryFloatCall(I, ISD::FSQRT))
           return;

llvm/lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp

#endif
   case ISD::FSQRT:                      return "fsqrt";
   case ISD::STRICT_FSQRT:               return "strict_fsqrt";
   case ISD::FCBRT:                      return "fcbrt";
   case ISD::FSIN:                       return "fsin";
   case ISD::STRICT_FSIN:                return "strict_fsin";
   case ISD::FCOS:                       return "fcos";
   case ISD::STRICT_FCOS:                return "strict_fcos";
   case ISD::FSINCOS:                    return "fsincos";
+  case ISD::FTAN:                       return "ftan";
   case ISD::FTRUNC:                     return "ftrunc";
   case ISD::STRICT_FTRUNC:              return "strict_ftrunc";
   case ISD::FFLOOR:                     return "ffloor";
   case ISD::STRICT_FFLOOR:              return "strict_ffloor";
   case ISD::FCEIL:                      return "fceil";
   case ISD::STRICT_FCEIL:               return "strict_fceil";
   case ISD::FRINT:                      return "frint";
   case ISD::STRICT_FRINT:               return "strict_frint";

llvm/lib/Target/X86/X86ISelLowering.cpp

auto setF16Action = [&] (MVT VT, LegalizeAction Action) {
     setOperationAction(ISD::FMA, VT, Action);
     setOperationAction(ISD::FMINNUM, VT, Action);
     setOperationAction(ISD::FMAXNUM, VT, Action);
     setOperationAction(ISD::FMINIMUM, VT, Action);
     setOperationAction(ISD::FMAXIMUM, VT, Action);
     setOperationAction(ISD::FSIN, VT, Action);
     setOperationAction(ISD::FCOS, VT, Action);
     setOperationAction(ISD::FSINCOS, VT, Action);
+    setOperationAction(ISD::FTAN, VT, Action);
     setOperationAction(ISD::FSQRT, VT, Action);
     setOperationAction(ISD::FPOW, VT, Action);
     setOperationAction(ISD::FLOG, VT, Action);
     setOperationAction(ISD::FLOG2, VT, Action);
     setOperationAction(ISD::FLOG10, VT, Action);
     setOperationAction(ISD::FEXP, VT, Action);
     setOperationAction(ISD::FEXP2, VT, Action);
     setOperationAction(ISD::FCEIL, VT, Action);
for (auto VT : { MVT::f32, MVT::f64 }) {
       // These might be better off as horizontal vector ops.
       setOperationAction(ISD::FADD, VT, Custom);
       setOperationAction(ISD::FSUB, VT, Custom);
 
       // We don't support sin/cos/fmod
       setOperationAction(ISD::FSIN   , VT, Expand);
       setOperationAction(ISD::FCOS   , VT, Expand);
       setOperationAction(ISD::FSINCOS, VT, Expand);
+      setOperationAction(ISD::FTAN   , VT, Expand);
     }
 
     // Half type will be promoted by default.
     setF16Action(MVT::f16, Promote);
     setOperationAction(ISD::FADD, MVT::f16, Promote);
     setOperationAction(ISD::FSUB, MVT::f16, Promote);
     setOperationAction(ISD::FMUL, MVT::f16, Promote);
     setOperationAction(ISD::FDIV, MVT::f16, Promote);
if (!Subtarget.useSoftFloat() && Subtarget.hasSSE2()) {
     if (UseX87)
       setOperationAction(ISD::FCOPYSIGN, MVT::f64, Expand);
     setOperationAction(ISD::FCOPYSIGN, MVT::f32, Custom);
 
     // We don't support sin/cos/fmod
     setOperationAction(ISD::FSIN   , MVT::f32, Expand);
     setOperationAction(ISD::FCOS   , MVT::f32, Expand);
     setOperationAction(ISD::FSINCOS, MVT::f32, Expand);
+    setOperationAction(ISD::FTAN   , MVT::f32, Expand);
 
     if (UseX87) {
       // Always expand sin/cos functions even though x87 has an instruction.
       setOperationAction(ISD::FSIN, MVT::f64, Expand);
       setOperationAction(ISD::FCOS, MVT::f64, Expand);
       setOperationAction(ISD::FSINCOS, MVT::f64, Expand);
+      setOperationAction(ISD::FTAN, MVT::f64, Expand);
     }
   } else if (UseX87) {
     // f32 and f64 in x87.
     // Set up the FP register classes.
     addRegisterClass(MVT::f64, &X86::RFP64RegClass);
     addRegisterClass(MVT::f32, &X86::RFP32RegClass);
 
     for (auto VT : { MVT::f32, MVT::f64 }) {
       setOperationAction(ISD::UNDEF,     VT, Expand);
       setOperationAction(ISD::FCOPYSIGN, VT, Expand);
 
       // Always expand sin/cos functions even though x87 has an instruction.
       setOperationAction(ISD::FSIN   , VT, Expand);
       setOperationAction(ISD::FCOS   , VT, Expand);
       setOperationAction(ISD::FSINCOS, VT, Expand);
+      setOperationAction(ISD::FTAN   , VT, Expand);
     }
   }
 
   // Expand FP32 immediates into loads from the stack, save special cases.
   if (isTypeLegal(MVT::f32)) {
     if (UseX87 && (getRegClassFor(MVT::f32) == &X86::RFP32RegClass)) {
       addLegalFPImmediate(APFloat(+0.0f)); // FLD0
       addLegalFPImmediate(APFloat(+1.0f)); // FLD1
setOperationAction(ISD::FCOPYSIGN, MVT::f80, Expand);
       TmpFlt2.changeSign();
       addLegalFPImmediate(TmpFlt2);  // FLD1/FCHS
     }
 
     // Always expand sin/cos functions even though x87 has an instruction.
     setOperationAction(ISD::FSIN   , MVT::f80, Expand);
     setOperationAction(ISD::FCOS   , MVT::f80, Expand);
     setOperationAction(ISD::FSINCOS, MVT::f80, Expand);
+    setOperationAction(ISD::FTAN   , MVT::f80, Expand);
 
     setOperationAction(ISD::FFLOOR, MVT::f80, Expand);
     setOperationAction(ISD::FCEIL,  MVT::f80, Expand);
     setOperationAction(ISD::FTRUNC, MVT::f80, Expand);
     setOperationAction(ISD::FRINT,  MVT::f80, Expand);
     setOperationAction(ISD::FNEARBYINT, MVT::f80, Expand);
     setOperationAction(ISD::FMA, MVT::f80, Expand);
     setOperationAction(ISD::LROUND, MVT::f80, Expand);
if (!Subtarget.useSoftFloat() && Subtarget.is64Bit() && Subtarget.hasSSE1()) {
     setOperationAction(ISD::FNEG, MVT::f128, Custom);
     setOperationAction(ISD::FCOPYSIGN, MVT::f128, Custom);
 
     setOperationAction(ISD::FSIN,         MVT::f128, LibCall);
     setOperationAction(ISD::STRICT_FSIN,  MVT::f128, LibCall);
     setOperationAction(ISD::FCOS,         MVT::f128, LibCall);
     setOperationAction(ISD::STRICT_FCOS,  MVT::f128, LibCall);
     setOperationAction(ISD::FSINCOS,      MVT::f128, LibCall);
+    setOperationAction(ISD::FTAN,         MVT::f128, LibCall);
     // No STRICT_FSINCOS
     setOperationAction(ISD::FSQRT,        MVT::f128, LibCall);
     setOperationAction(ISD::STRICT_FSQRT, MVT::f128, LibCall);
 
     setOperationAction(ISD::FP_EXTEND,        MVT::f128, Custom);
     setOperationAction(ISD::STRICT_FP_EXTEND, MVT::f128, Custom);
     // We need to custom handle any FP_ROUND with an f128 input, but
     // LegalizeDAG uses the result type to know when to run a custom handler.
X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM,
 
   // Some FP actions are always expanded for vector types.
   for (auto VT : { MVT::v8f16, MVT::v16f16, MVT::v32f16,
                    MVT::v4f32, MVT::v8f32,  MVT::v16f32,
                    MVT::v2f64, MVT::v4f64,  MVT::v8f64 }) {
     setOperationAction(ISD::FSIN,      VT, Expand);
     setOperationAction(ISD::FSINCOS,   VT, Expand);
     setOperationAction(ISD::FCOS,      VT, Expand);
+    setOperationAction(ISD::FTAN,      VT, Expand);
     setOperationAction(ISD::FREM,      VT, Expand);
     setOperationAction(ISD::FCOPYSIGN, VT, Expand);
     setOperationAction(ISD::FPOW,      VT, Expand);
     setOperationAction(ISD::FLOG,      VT, Expand);
     setOperationAction(ISD::FLOG2,     VT, Expand);
     setOperationAction(ISD::FLOG10,    VT, Expand);
     setOperationAction(ISD::FEXP,      VT, Expand);
     setOperationAction(ISD::FEXP2,     VT, Expand);
for (ISD::NodeType Op :
          {ISD::FCEIL,  ISD::STRICT_FCEIL,
           ISD::FCOS,   ISD::STRICT_FCOS,
           ISD::FEXP,   ISD::STRICT_FEXP,
           ISD::FFLOOR, ISD::STRICT_FFLOOR,
           ISD::FREM,   ISD::STRICT_FREM,
           ISD::FLOG,   ISD::STRICT_FLOG,
           ISD::FLOG10, ISD::STRICT_FLOG10,
           ISD::FPOW,   ISD::STRICT_FPOW,
-          ISD::FSIN,   ISD::STRICT_FSIN})
+          ISD::FSIN,   ISD::STRICT_FSIN,
+          ISD::FTAN})
       if (isOperationExpand(Op, MVT::f32))
         setOperationAction(Op, MVT::f32, Promote);
 
   // We have target-specific dag combine patterns for the following nodes:
   setTargetDAGCombine({ISD::VECTOR_SHUFFLE,
                        ISD::SCALAR_TO_VECTOR,
                        ISD::INSERT_VECTOR_ELT,
                        ISD::EXTRACT_VECTOR_ELT,

llvm/test/CodeGen/X86/llvm.tan.ll

+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 2
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+define float @use_tanf32(float %a) {
+; CHECK-LABEL: use_tanf32:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    jmp tanf@PLT # TAILCALL
+  %x = call float @llvm.tan.f32(float %a)
+  ret float %x
+}
+
+define double @use_tanf64(double %a) {
+; CHECK-LABEL: use_tanf64:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    jmp tan@PLT # TAILCALL
+  %x = call double @llvm.tan.f64(double %a)
+  ret double %x
+}
+
+define fp128 @use_tanfp128(fp128 %a) {
+; CHECK-LABEL: use_tanfp128:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    jmp tanl@PLT # TAILCALL
+  %x = call fp128 @llvm.tan.f128(fp128 %a)
+  ret fp128 %x
+}
+
+define ppc_fp128 @use_tanppc_fp128(ppc_fp128 %a) {
+; CHECK-LABEL: use_tanppc_fp128:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    pushq %rax
+; CHECK-NEXT:    .cfi_def_cfa_offset 16
+; CHECK-NEXT:    callq tanl@PLT
+; CHECK-NEXT:    popq %rax
+; CHECK-NEXT:    .cfi_def_cfa_offset 8
+; CHECK-NEXT:    retq
+  %x = call ppc_fp128 @llvm.tan.ppcf128(ppc_fp128 %a)
+  ret ppc_fp128 %x
+}
+
+declare float @llvm.tan.f32(float)
+declare double @llvm.tan.f64(double)
+declare fp128 @llvm.tan.f128(fp128)
+declare ppc_fp128 @llvm.tan.ppcf128(ppc_fp128)
+