-ffast-math optimizations impacted by symbol renaming in header files

Hi,

I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target.

I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the __FINITE_MATH_ONLY__ macro set to 1. In this case, the Linux header files are redirecting several math functions using the __asm__ extension to rename the symbol. An example of what the header files contains is:
      extern double exp (double) __asm__ ("" "__exp_finite") __attribute__ ((__nothrow__ ));

In effect, ‘exp’ gets converted to be ‘__exp_finite’ in the IR. Because some of the optimizations like constant folding or vectorization are looking for the original function name, those optimizations do not get triggered under –ffast-math due to these alternative function names.

Other affected functions include: acos, asin, exp2, log, log2, log10, and a few others.

Anybody know if this is intentional, or have input regarding whether these optimizations should be extended to also look for the renamed versions of these functions?

Thanks,
Chris

A couple of example cases:

// File: test_folding.c

// Constant fold will occur with:
// clang -O2 -S -emit-llvm test_folding.c

// Constant fold will not occur with:
// clang -O2 -S -emit-llvm -ffast-math test_folding.c

#include <math.h>

double test_fold_exp() {
  return exp(0.0);
}

double test_fold_acos() {
  return acos(1.0);
}

Hi,

I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target.

I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the __FINITE_MATH_ONLY__ macro set to 1. In this case, the Linux header files are redirecting several math functions using the __asm__ extension to rename the symbol. An example of what the header files contains is:
       extern double exp (double) __asm__ ("" "__exp_finite") __attribute__ ((__nothrow__ ));

In effect, ‘exp’ gets converted to be ‘__exp_finite’ in the IR. Because some of the optimizations like constant folding or vectorization are looking for the original function name, those optimizations do not get triggered under –ffast-math due to these alternative function names.

Other affected functions include: acos, asin, exp2, log, log2, log10, and a few others.

Anybody know if this is intentional, or have input regarding whether these optimizations should be extended to also look for the renamed versions of these functions?

It is not intentional; the optimizations should be extended. I imagine that we would extend TargetLibraryInfo to have names for these functions, and then we could recognize them when available, and generate them when available and the inputs have the 'fast' tag.

  -Hal

Thanks Hal,

I’ll take a look into extending the TargetLibraryInfo.

Chris

Hi,

I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target.

I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the FINITE_MATH_ONLY macro set to 1. In this case, the Linux header files are redirecting several math functions using the asm extension to rename the symbol. An example of what the header files contains is:
extern double exp (double) asm ("" “__exp_finite”) attribute ((nothrow ));

In effect, ‘exp’ gets converted to be ‘__exp_finite’ in the IR. Because some of the optimizations like constant folding or vectorization are looking for the original function name, those optimizations do not get triggered under –ffast-math due to these alternative function names.

Other affected functions include: acos, asin, exp2, log, log2, log10, and a few others.

Anybody know if this is intentional, or have input regarding whether these optimizations should be extended to also look for the renamed versions of these functions?

It is not intentional; the optimizations should be extended. I imagine
that we would extend TargetLibraryInfo to have names for these
functions, and then we could recognize them when available, and generate
them when available and the inputs have the ‘fast’ tag.

-Hal

Hi,

I have an implementation for extending the target library info with additional math functions that get called when the header files pull in alternative versions during the use of –ffast-math so that calls to those can be optimized (http://lists.llvm.org/pipermail/llvm-dev/2017-March/111323.html).

I’m hoping someone can perform a code review and commit for me. When I tried to select ‘llvm-commits’ in the subscriber list of Phabricator, the name is crossed out for me, and mails do not seem to be going out for it, so I’m sending mail here. (If anybody knows why it is crossed out, and how I can fix this, please let me know).

Anyway, if someone could review the code changes posted, that would be greatly appreciated. I have broken down the changes into 3 changesets to minimize the deltas for each.
https://reviews.llvm.org/D31787
https://reviews.llvm.org/D31788
https://reviews.llvm.org/D31789

Thanks,

Chris

Thanks Hal,

I’ll take a look into extending the TargetLibraryInfo.

Chris

Hi,

I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target.

I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the FINITE_MATH_ONLY macro set to 1. In this case, the Linux header files are redirecting several math functions using the asm extension to rename the symbol. An example of what the header files contains is:
extern double exp (double) asm ("" “__exp_finite”) attribute ((nothrow ));

In effect, ‘exp’ gets converted to be ‘__exp_finite’ in the IR. Because some of the optimizations like constant folding or vectorization are looking for the original function name, those optimizations do not get triggered under –ffast-math due to these alternative function names.

Other affected functions include: acos, asin, exp2, log, log2, log10, and a few others.

Anybody know if this is intentional, or have input regarding whether these optimizations should be extended to also look for the renamed versions of these functions?

It is not intentional; the optimizations should be extended. I imagine
that we would extend TargetLibraryInfo to have names for these
functions, and then we could recognize them when available, and generate
them when available and the inputs have the ‘fast’ tag.

-Hal