This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Standard] Add `atan` to standard dialect
ClosedPublic

Authored by frgossen on Sep 22 2020, 5:54 AM.

Diff Detail

Event Timeline

frgossen created this revision.Sep 22 2020, 5:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2020, 5:54 AM
frgossen requested review of this revision.Sep 22 2020, 5:54 AM
jpienaar added inline comments.Sep 22 2020, 6:07 AM
mlir/include/mlir/Dialect/StandardOps/IR/Ops.td
517

These need an update

herhut accepted this revision.Sep 22 2020, 6:11 AM

Please fix the comment.

This revision is now accepted and ready to land.Sep 22 2020, 6:11 AM
frgossen updated this revision to Diff 293434.Sep 22 2020, 6:15 AM
frgossen marked an inline comment as done.

Fix documentation

This revision was landed with ongoing or failed builds.Sep 22 2020, 6:17 AM
This revision was automatically updated to reflect the committed changes.

I can't find a discussion and rationale on Discourse, was this discussed?
LLVM does not have intrinsics for atan I believe, it is just a libcall: what is the tradeoff about adding it to standard here?

bondhugula added a subscriber: bondhugula.EditedSep 23 2020, 12:01 AM

I can't find a discussion and rationale on Discourse, was this discussed?
LLVM does not have intrinsics for atan I believe, it is just a libcall: what is the tradeoff about adding it to standard here?

Standard ML dialects have an atan op - xla_hlo/mhlo has it and others at that level would too. In order to be able to lower such ops to ops on scalar values (either stemming from 0-d tensor types or inside nests) for mid/low-level backends and to canonicalize/simplify such ops like others, one would need an abstraction in the std dialect. (Otherwise, we'd have to jump from lmhlo to call's early or to the LLVM dialect straight from there?). As far as the LLVM dialect not having intrinsics for a std dialect op goes, that way, the LLVM dialect doesn't have intrinsics for our alloc's and dealloc's as well. We just lower them to llvm.call to malloc, aligned_alloc, and free. However, LLVM does have support for these libcalls in its TLI that allow a lot of detection and optimization around these.

We do not intend to add a standard lowering for atan as there would be many possible approximations.
Like @bondhugula said, it helps us with the lowering from lmhlo to std where we can subsequently apply our approximation.
Sorry for the missing discussion on Discourse. Should I still post it?