Page MenuHomePhabricator

[Polly] [PPCGCodeGeneration] Convert intrinsics to libdevice functions whenever possible.

Authored by bollu on Aug 23 2017, 3:11 AM.



This is useful when we face certain intrinsics such as llvm.exp.*
which cannot be lowered by the NVPTX backend while other intrinsics can.

So, we would need to keep blacklists of intrinsics that cannot be
handled by the NVPTX backend. It is much simpler to try and promote
all intrinsics to libdevice versions.

This patch makes function/intrinsic very uniform, and will always try to use
a libdevice version if it exists.

Diff Detail


Event Timeline

bollu created this revision.Aug 23 2017, 3:11 AM
bollu updated this revision to Diff 112331.Aug 23 2017, 4:47 AM
  • [Bugfix] add powi to the list of instructions that the NVPTX backend cannot lower.
  • [NFC] remove debug code
bollu retitled this revision from [Polly] [PPCGCodeGeneration] [WIP] Convert intrinsics to libdevice functions whenever possible. to [Polly] [PPCGCodeGeneration] Convert intrinsics to libdevice functions whenever possible..Aug 23 2017, 4:48 AM

I should probably split this into two patches, but I wanted to run the idea by. I can split it when I commit (or split it now). Review, please.

bollu updated this revision to Diff 112337.Aug 23 2017, 5:21 AM
  • [Test] upadte tests to refect state of exp, powi in PPCGCodeGen
efriedma edited edge metadata.Aug 23 2017, 12:21 PM

Why can't the LLVM NVPTX backend handle these intrinsics? If implementations are available, the backend should call them. Or am I missing something obvious?

bollu added a comment.Aug 24 2017, 3:01 AM

@efriedma - The NVPTX backend does not lower either llvm.exp.* or llvm.powi.* (Unless I am doing something wrong).

Hmm, looks like it doesn't work (I get "LLVM ERROR: Cannot select: t14: i32 = ExternalSymbol'__powisf2'"). But that's clearly a bug in the backend rather than something you should try to address in polly.

bollu added a comment.Aug 25 2017, 8:18 AM

@grosser ping, review please.

grosser accepted this revision.Aug 25 2017, 9:35 AM

Hi Eli,

you are right. It would be nice if the backend would directly include libdevice. There is some information about libdevice available at, but it seems it is indeed expected to be linked before things are passed to the LLVM backend.

Siddharth, can you please open a bug report regarding the issue Eli mentioned? Eli, do you think it is OK to move ahead for now, until this issue has been solved in the LLVM backend. (We are happy to add the necessary code, but this likely first needs some discussion.) Siddharth, maybe you can even open a discussion on llvm-dev?


This revision is now accepted and ready to land.Aug 25 2017, 9:35 AM

Yes, it's okay for now.

1420 ↗(On Diff #112337)

Instead of trying to parse the name of the intrinsic, could you just map from an exact llvm intrinsic name to the equivalent libdevice function? e.g. map llvm.powi.f32 to __nv_powif, llvm.powi.f64 to __nv_powi, etc.

bollu updated this revision to Diff 112862.Aug 28 2017, 2:19 AM
  • Don't parse the function name, keep a static map from intrinsic names to libdevice names
bollu updated this revision to Diff 112864.Aug 28 2017, 2:37 AM
  • [Diff update] Update diff with latest master.
bollu marked an inline comment as done.Aug 28 2017, 3:31 AM

@efriedma I made the changes you requested. Could you have a final look, please?

This revision was automatically updated to reflect the committed changes.