This is an archive of the discontinued LLVM Phabricator instance.

[TLI] Add declarations for various math header file routines from math-finite.h that create '__<func>_finite as functions
ClosedPublic

Authored by chrischr on Apr 6 2017, 2:48 PM.

Details

Summary

This is the first of a set of patches to followup on the thread in http://lists.llvm.org/pipermail/llvm-dev/2017-March/111323.html

When -ffast-math is enabled, various math function names get redirected by the FE to alternate versions. This happens because the -ffast-math option causes the math.h header file to be preprocessed with the macro FINITE_MATH_ONLY set to 1, which causes some asm statements to be processed that rename certain math functions.

For example, 'exp' gets put into the IR as '__exp_finite'

The alternate versions are currently not recognized by the optimizer, which results in some missed optimizations opportunities that would have been handled without the -ffast-math flag.

This change adds important functions to the target library info table. Subsequent patches will make use of this change to add some of these function for cases of constant folding or vectorization.

Diff Detail

Repository
rL LLVM

Event Timeline

chrischr created this revision.Apr 6 2017, 2:48 PM
chrischr edited the summary of this revision. (Show Details)Apr 24 2017, 1:48 PM

Can you add tests for these changes? I think the attribute.ll and no-proto.ll tests in test/Transforms/InferFunctionAttrs would be the right place to add these. I'm not sure if the existing tests check all of the LibFunc calls or just a representative sample.

include/llvm/Analysis/TargetLibraryInfo.def
165 ↗(On Diff #94439)

Is there a reason for these being inserted where they are? It looks rather arbitrary.

chrischr added inline comments.May 2 2017, 8:10 AM
include/llvm/Analysis/TargetLibraryInfo.def
165 ↗(On Diff #94439)

The list needs to be created in sorted order based on the value of the string definition.

static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
                       ArrayRef<StringRef> StandardNames) {
  // Verify that the StandardNames array is in alphabetical order.
  assert(std::is_sorted(StandardNames.begin(), StandardNames.end(),
                        [](StringRef LHS, StringRef RHS) {
                          return LHS < RHS;
                        }) &&
         "TargetLibraryInfoImpl function names must be sorted");
andrew.w.kaylor added inline comments.May 2 2017, 2:23 PM
include/llvm/Analysis/TargetLibraryInfo.def
165 ↗(On Diff #94439)

OK. That makes sense now.

What about a test?

ab added a subscriber: ab.May 2 2017, 2:35 PM

This looks fine; the TLI unittest is the best place for testing this. (for instance, no-proto.ll wouldn't help, because the pass doesn't know about these libfuncs and can't modify them anyway, regardless of the prototype)

Beyond that, I'm curious: should these be added as names only, and treated as "aliases" of the non-finite functions (only when -ffinite-math-only) ? Or, put another way: is it ever desirable to distinguish between them?

chrischr updated this revision to Diff 97511.May 2 2017, 3:28 PM

New version uploaded which adds changes to the unit test files in test/Transformas/InferFnctionAttrs to include the newly added TLI function prototypes.

@ Andrew: New files uploaded for additional testing for function prototype matching. Although for the TargetLibraryInfo.def, test coverage should be coming about from the unittests/Analysis/TargetLibraryInfoTest.cpp test case, since this verifies that every function listed in the .def file gets matched against the definition in this test case.

@ ab: I looked back at the TargetLibraryInfo code, but don't see any support for indicating function aliases there. However, I don't think it would be desirable to map them to be the same as the non-finite version, because while during some of the optimization phases they need to be treated similarly, when it comes to the code generation phase they need to be treated uniquely to call either the regular version or the finite version to get the optimized library version.

include/llvm/Analysis/TargetLibraryInfo.def
165 ↗(On Diff #94439)

BTW, the test. unittests/Analysis/TargetLibraryInfoTest.cpp. checks that every function in the TLI table can be looked up.

andrew.w.kaylor accepted this revision.May 8 2017, 11:54 AM

Looks good to me.

This revision is now accepted and ready to land.May 8 2017, 11:54 AM
lib/Analysis/TargetLibraryInfo.cpp
243 ↗(On Diff #97511)

Am I reading this correctly as saying these will only be marked as unavailable for 32-bit Windows targets? The comment implies they should be unavailable for all Windows targets, right?

chrischr added inline comments.May 9 2017, 10:41 AM
lib/Analysis/TargetLibraryInfo.cpp
243 ↗(On Diff #97511)

Good point, you are correct. These should be moved outside of this 'if' condition. I'll fix and upload a new revision.

chrischr updated this revision to Diff 98468.May 10 2017, 8:47 AM

Fixed calls to SetUnavailable to be for Windows, not just Windows x86.

Still approved.

Do you need someone to commit this for you?

Still approved.
Do you need someone to commit this for you?

Yes, please. Thanks in advance!

This revision was automatically updated to reflect the committed changes.