[Gelu x86] Finish intrinsic with elempack merged(fast version)

[LRY89757]

• 实现了Gelu的x86平台优化
• 仅使用了fast gelu版本，也就是近似版本的erfc:
  
• 添加了tanh的mathfunc sse/avx/avx512实现
• 添加了test_sample追求覆盖率.

[codecov-commenter]

Codecov Report

Merging #4144 (6e9cf57) into master (9f59711) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #4144      +/-   ##
==========================================
+ Coverage   94.41%   94.44%   +0.03%     
==========================================
  Files         749      750       +1     
  Lines      179061   179180     +119     
==========================================
+ Hits       169053   169222     +169     
+ Misses      10008     9958      -50     

Impacted Files	Coverage Δ
src/layer/x86/avx512_mathfun.h	100.00% <100.00%> (ø)
src/layer/x86/avx_mathfun.h	100.00% <100.00%> (ø)
src/layer/x86/gelu_x86.cpp	100.00% <100.00%> (ø)
src/layer/x86/sse_mathfun.h	100.00% <100.00%> (ø)
src/layer/riscv/convolution1d_riscv.cpp	99.00% <0.00%> (+0.24%)	⬆️
src/layer/riscv/convolution_3x3_packn_fp16s.h	99.48% <0.00%> (+0.51%)	⬆️
src/layer/riscv/convolution_3x3_pack1ton_fp16s.h	100.00% <0.00%> (+10.85%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[LRY89757]

1. 请教一个问题，关于mathfun.h这里的定义宏，为什么要这么定义一个这样的宏：

/* declare some AVX constants -- why can't I figure a better way to do that? */
#define _PS512_CONST(Name, Val) \
    static const ALIGN64_BEG float _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PI32_CONST512(Name, Val) \
    static const ALIGN64_BEG int _pi32_512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PS512_CONST_TYPE(Name, Type, Val) \
    static const ALIGN64_BEG Type _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}

不应该直接使用_mm_set1_ps这类函数就可以了吗？是有着什么更深的用意吗？

2. 关于tanh的实现这里暂时借用了exp， 非常naive的一种实现，单独专门的simd x86优化正在做 [WIP]（已实现）

[LRY89757]

实现了tanh的fast simd x86版本

[nihui]

1. 请教一个问题，关于mathfun.h这里的定义宏，为什么要这么定义一个这样的宏：

/* declare some AVX constants -- why can't I figure a better way to do that? */
#define _PS512_CONST(Name, Val) \
    static const ALIGN64_BEG float _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PI32_CONST512(Name, Val) \
    static const ALIGN64_BEG int _pi32_512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PS512_CONST_TYPE(Name, Type, Val) \
    static const ALIGN64_BEG Type _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}

不应该直接使用_mm_set1_ps这类函数就可以了吗？是有着什么更深的用意吗？

2. ~关于`tanh`的实现这里暂时借用了`exp`， 非常naive的一种实现，单独专门的`simd x86`优化正在做 **[WIP]**~（已实现）

这可能得请教原作者，目前的写法很可能是与编译器斗智斗勇的结果

猜测

• __m256 这样的寄存器无法写作全局静态的变量，结局就是编译器把这些数值放在全局静态区中，运行时载入
• 编译器可能会不对齐的存放数据，于是作者干脆直接写成数组，并强制要求对齐，提升运行时载入效率

[LRY89757]

1. 请教一个问题，关于mathfun.h这里的定义宏，为什么要这么定义一个这样的宏：

/* declare some AVX constants -- why can't I figure a better way to do that? */
#define _PS512_CONST(Name, Val) \
    static const ALIGN64_BEG float _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PI32_CONST512(Name, Val) \
    static const ALIGN64_BEG int _pi32_512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}
#define _PS512_CONST_TYPE(Name, Type, Val) \
    static const ALIGN64_BEG Type _ps512_##Name[16] ALIGN64_END = {Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val, Val}

不应该直接使用_mm_set1_ps这类函数就可以了吗？是有着什么更深的用意吗？

2. ~关于`tanh`的实现这里暂时借用了`exp`， 非常naive的一种实现，单独专门的`simd x86`优化正在做 **[WIP]**~（已实现）

这可能得请教原作者，目前的写法很可能是与编译器斗智斗勇的结果

猜测

• __m256 这样的寄存器无法写作全局静态的变量，结局就是编译器把这些数值放在全局静态区中，运行时载入
• 编译器可能会不对齐的存放数据，于是作者干脆直接写成数组，并强制要求对齐，提升运行时载入效率

Got it, thanks for guidance. I will improve the codes as soon as possible.

[LRY89757]

已经按照对应的指导改正代码格式，同时也修正添加了create_pipeline函数用来回退版本

有一个进一步问题，既然我此前x86 simd代码全部使用的是fast_gelu用来计算，同时test函数并没有报错，是否这意味着我们没有必要使用erfc来进行推理而直接全部使用fast_gelu版本来进行计算即可，因为两者计算出来的结果几乎没有误差？
如果有必要的话我会把simd版本的erfc加上去

[nihui]

已经按照对应的指导改正代码格式，同时也修正添加了create_pipeline函数用来回退版本

有一个进一步问题，既然我此前x86 simd代码全部使用的是fast_gelu用来计算，同时test函数并没有报错，是否这意味着我们没有必要使用erfc来进行推理而直接全部使用fast_gelu版本来进行计算即可，因为两者计算出来的结果几乎没有误差？ 如果有必要的话我会把simd版本的erfc加上去

没有必要，erfc 在 naive 实现里面就足够了，为的就是参考一下
目前pnnx那边转出ncnn的gelu一律会设置 fast_gelu=1

[nihui]

Thanks for your contribution !