Handle sequence_lens for GRU on CPU

[chentong319]

This PR is a quick fix for sequence_lens. According to the definition from PyTorch, padding value is added after a sequence reaches its sequence lens. This PR does not try to save the computation. I will try another PR to use scf.if so that all the RNN op can be handled and computation will be saved.
The output of my test case of GRU seems to conform with the PyTorch example.

module{
func.func @main_graph(%arg0: tensor<2x2x1xf32>, %arg1: tensor<1x3x1xf32>, %arg2 : tensor<1x3x1xf32>) -> (tensor<*xf32>, tensor<*xf32>) {
  %lens = onnx.Constant dense<[2, 1]> : tensor<2xi32>
  %cst = "onnx.NoValue"() {value} : () -> none
  %Y, %Y_h = "onnx.GRU"(%arg0, %arg1, %arg2, %cst, %lens, %cst) : ( tensor<2x2x1xf32>, tensor<1x3x1xf32>, tensor<1x3x1xf32>, none, tensor<2xi32>, none) -> (tensor<*xf32>, tensor<*xf32>)
 onnx.Return %Y, %Y_h : tensor<*xf32>, tensor<*xf32>
}
"onnx.EntryPoint"() {func = @main_graph} : () -> ()
}

The output is

The 1st output output_1:[2x1x2x1xfloat32] is: 
 [[[[ 0.0011079 ]
   [-0.00399583]]]


 [[[-0.001489  ]
   [ 0.        ]]]] 

The 2nd output output_1:[1x2x1xfloat32] is: 
 [[[-0.001489]
  [ 0.      ]]]

Limitations: This PR does not save computation with the sequence_lens info. To do that, I can add a scf.if within the loop for sequence and batch. However, the existing implementation defines the loop nest for batch and hidden state together. Need some efforts to break the loop nest. It is doable. But priority?

Question: should the final result be modified according to the sequence_lens? For example, should the 2nd output be [[[-0.001489] [-0.00399583]]]? I did not find any specification for that.

[chentong319]

Another test case for the initialH.

module{
func.func @main_graph(%arg0: tensor<4x3x1xf32>, %arg1: tensor<1x6x1xf32>, %arg2 : tensor<1x6x2xf32>) -> (tensor<*xf32>, tensor<*xf32>) {
  %lens = onnx.Constant dense<[2,3,1]> : tensor<3xi32>
  %initial = onnx.Constant dense<[[[0., 1.],[2.0, 3.0],[4.0, 5.0]]]> : tensor<1x3x2xf32>
  %cst = "onnx.NoValue"() {value} : () -> none
  %Y, %Y_h = "onnx.GRU"(%arg0, %arg1, %arg2, %cst, %lens, %initial) : 
    ( tensor<4x3x1xf32>, tensor<1x6x1xf32>, tensor<1x6x2xf32>, none, tensor<3xi32>, tensor<1x3x2xf32>) 
    -> (tensor<*xf32>, tensor<*xf32>)
 onnx.Return %Y, %Y_h : tensor<*xf32>, tensor<*xf32>
}
"onnx.EntryPoint"() {func = @main_graph} : () -> ()
}

The result:

The 1st output output_1:[4x1x3x2xfloat32] is: 
 [[[[1.2503355e-03 4.5813003e-01]
   [8.9796937e-01 1.2981267e+00]
   [1.6873405e+00 2.0353923e+00]]]


 [[[5.4413028e-04 2.1451449e-01]
   [4.2194879e-01 5.9896427e-01]
   [4.0000000e+00 5.0000000e+00]]]


 [[[0.0000000e+00 1.0000000e+00]
   [2.0093442e-01 2.8191486e-01]
   [4.0000000e+00 5.0000000e+00]]]


 [[[0.0000000e+00 1.0000000e+00]
   [2.0000000e+00 3.0000000e+00]
   [4.0000000e+00 5.0000000e+00]]]] 

The 2nd output output_1:[1x3x2xfloat32] is: 
 [[[0. 1.]
  [2. 3.]
  [4. 5.]]] 

[tungld]

Could we create a common function for this to avoid boilerplate? and we can call it in other ops like LSTM and RNN.

[chentong319]

Changed.

[chentong319]

Now both the first and second output of GRU are the same as the torch GRU example.

[tungld]

LGTM!

[jenkins-droid]

Jenkins Linux s390x Build #12569 [push] Handle sequence_lens for... started at 20:04

[jenkins-droid]

Jenkins Linux ppc64le Build #11562 [push] Handle sequence_lens for... started at 20:13

[jenkins-droid]

Jenkins Linux amd64 Build #12557 [push] Handle sequence_lens for... started at 19:04

[jenkins-droid]

Jenkins Linux amd64 Build #12557 [push] Handle sequence_lens for... passed after 1 hr 5 min

[jenkins-droid]

Jenkins Linux s390x Build #12569 [push] Handle sequence_lens for... passed after 1 hr 24 min

[jenkins-droid]

Jenkins Linux ppc64le Build #11562 [push] Handle sequence_lens for... passed after 1 hr 44 min