Roll back ipow changes due to register pressure.

[pmattione-nvidia]

The addition of an array of integers in this function placed too much register pressure on our code base. This function is used by the fixed_point constructor and cast operators, so it potentially affects every kernel. Too many unrelated kernels were impacted and suffered performance degradations to justify this change. This reverts the algorithm introduced in #15110 to what it was previously, with some very minor tweaks.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[GregoryKimball]

Adding @shrshi and @PointKernel as reviewers based on their previous analysis of #15110

[PointKernel]

@pmattione-nvidia I recall you mentioned that using a smaller lookup table can get about the same performance without introducing too much register pressure. How did that go?

[pmattione-nvidia]

I tried that and everything I could think of, but several tests were still just too sensitive. It's not clear to me that they were even using decimal types at all, but they were slowing down significantly regardless (a few tests were still 5-10% slower).

[PointKernel]

LGTM

I pinned the original PR in the PR description for easy backtrace. We can revisit the recursive solution once the mixed join has been refactored with the new cuco set (which is supposed to relieve the register pressure a bit). Also, I've sent you the instructions for setting up signed commits via slack. The CI will automatically once it's done.

[pmattione-nvidia]

/ok to test

[mythrocks]

LGTM. This branch might need an upmerge.

[pmattione-nvidia]

/merge