support lowering for aten.log1p

[zezhang]

Lower aten.log1p op to tcp.log(tcp.add(input, 1.0))

To test:

bazel test //... (in docker)

[jain-sambhaav]

Can you add this to the aot_compile test suite for e2e coverage?

[sjain-stanford]

LGTM to land after this is added to aot_compile suite.

[zezhang]

Can you add this to the aot_compile test suite for e2e coverage?

Just added.

[sjain-stanford]

There are two parity failures.

[ RUN      ] AotCompiled.ExecuteTest

bazel-out/k8-fastbuild/bin/test/AotCompile/_internal_log1p_execute_test.cpp:139: Failure
Expected equality of these values:
  Result.Output0.data[i]
    Which is: -0.0529[184](https://github.com/cruise-automation/mlir-tcp/actions/runs/10687447249/job/29625079316#step:9:185)45
  refOutput0.data<float>()[i]
    Which is: -0.052918427

bazel-out/k8-fastbuild/bin/test/AotCompile/_internal_log1p_execute_test.cpp:139: Failure
Expected equality of these values:
  Result.Output0.data[i]
    Which is: -nan
  refOutput0.data<float>()[i]
    Which is: -nan

We use EXPECT_FLOAT_EQ which checks two fp numbers are equal within 4 ULPs. Since this exceeds it, we might want to use a custom tolerance maybe with EXPECT_NEAR? Also not sure how this works for nans.

[zezhang]

There are two parity failures.

[ RUN      ] AotCompiled.ExecuteTest

bazel-out/k8-fastbuild/bin/test/AotCompile/_internal_log1p_execute_test.cpp:139: Failure
Expected equality of these values:
  Result.Output0.data[i]
    Which is: -0.0529[184](https://github.com/cruise-automation/mlir-tcp/actions/runs/10687447249/job/29625079316#step:9:185)45
  refOutput0.data<float>()[i]
    Which is: -0.052918427

bazel-out/k8-fastbuild/bin/test/AotCompile/_internal_log1p_execute_test.cpp:139: Failure
Expected equality of these values:
  Result.Output0.data[i]
    Which is: -nan
  refOutput0.data<float>()[i]
    Which is: -nan

We use EXPECT_FLOAT_EQ which checks two fp numbers are equal within 4 ULPs. Since this exceeds it, we might want to use a custom tolerance maybe with EXPECT_NEAR? Also not sure how this works for nans.

Right.... from PyTorch Website Looks like log1p is better used with small input values.

[sjain-stanford]

Yeah you might want to try constraining the inputs to be positive and small (instead of torch.randn in the loader) since log(1+x) is only defined for 1+x > 0.