Page MenuHomePhabricator

[FPEnv][X86] Platform builtins edition: clang should get from the AST the metadata for constrained FP builtins
Needs ReviewPublic

Authored by kpn on Wed, Jan 13, 10:04 AM.

Details

Summary

Currently clang is not correctly retrieving from the AST the metadata for constrained FP builtins. This patch fixes that for the X86 specific builtins.

For previous work in this vein see D92122 for example.

Diff Detail

Unit TestsFailed

TimeTest
1,750 msx64 windows > Clang.CodeGen/X86::avx512dq-builtins-constrained.c
Script: -- : 'RUN: at line 2'; c:\ws\w16-1\llvm-project\premerge-checks\build\bin\clang.exe -cc1 -internal-isystem c:\ws\w16-1\llvm-project\premerge-checks\build\lib\clang\12.0.0\include -nostdsysteminc -flax-vector-conversions=none -ffreestanding C:\ws\w16-1\llvm-project\premerge-checks\clang\test\CodeGen\X86\avx512dq-builtins-constrained.c -triple=x86_64-apple-darwin -target-feature +avx512dq -emit-llvm -o - -Wall -Werror | c:\ws\w16-1\llvm-project\premerge-checks\build\bin\filecheck.exe C:\ws\w16-1\llvm-project\premerge-checks\clang\test\CodeGen\X86\avx512dq-builtins-constrained.c --check-prefix=UNCONSTRAINED --check-prefix=COMMON --check-prefix=COMMONIR

Event Timeline

kpn created this revision.Wed, Jan 13, 10:04 AM
kpn requested review of this revision.Wed, Jan 13, 10:04 AM

Hi Kevin, what's the intention of adding constrained FP metadata for target dependent builtins? I believe the middle-end passes always ignore these builtins. What's more, will it imply user these builtins have different behaviors under different FP model? But it's not true for most platform builtins, since they are just representative of given instructions.

kpn added a comment.Thu, Jan 14, 8:12 AM

This doesn't add metadata to llvm intrinsics that are not constrained.

The metadata is added by the IRBuilder when the IRBuilder is used to add constrained intrinsics. When adding non-constrained intrinsics that have a direct mapping to constrained intrinsics, and constrained mode is enabled, the IRBuilder will add a constrained intrinsic instead of the requested non-constrained intrinsic. This keeps the changes to the front-end smaller.

But the metadata is _only_ added when the IRBuilder knows it is adding a constrained intrinsic. So we're not adding anything to any of the other llvm intrinsics. The target-specific llvm intrinsics are no exception to this rule.

Some of the clang builtins get lowered in whole or in part to llvm instructions (or constrained FP calls). Currently they use the metadata specified by the command line arguments. This change causes them to pick up the metadata that the AST says should be used. If no #pragma was used then the AST will be carrying the metadata from the command line. If a relevant #pragma is used then without this change the metadata in the #pragma's scope will be wrong. I'm testing for this by having the RUN lines specify "maytrap" but then use the #pragma float_control to switch to "fpexcept.strict".

The IRBuilder's idea of the current metadata is updated by CGFPOptionsRAII. That's why you see it used right around places where we leave the clang AST and call into code that doesn't have access to the AST. Like the IRBuilder.

A similar issue exists with the rounding-mode metadata. But both rounding and exception behavior are set by CGFPOptionsRAII, and if that changes then other tests already in the tree will fail. So I'm not bothering with rounding metadata testing here.

It's true that the middle-end optimizers know nothing about the constrained intrinsics. Today. I plan on changing that in the near future.

If use of the constrained intrinsics will cause breakage of the target-specific clang builtins then that's important to know and to fix. And I don't know all the targets well enough to know if that is a problem. So I'm going around asking target-specific developers to take another look and make sure we aren't setting ourselves up for problems later by having these builtins lower with the correct metadata for this point in the AST.

This doesn't add metadata to llvm intrinsics that are not constrained.

Oh, right. I misunderstood what's doing in these patches and thought we can add metadata to any intrinsics by CGFPOptionsRAII now. :-)

If a relevant #pragma is used then without this change the metadata ...

Yeah, I understand it now. Thank you! But why we still have the wrong maytrap with this patch?

It's true that the middle-end optimizers know nothing about the constrained intrinsics. Today. I plan on changing that in the near future.

Brilliant!

If use of the constrained intrinsics will cause breakage of the target-specific clang builtins then that's important to know and to fix.

I had a look at these changes and didn't find anything will cause breakage for now. I'm still not sure if we need to teach target-specific clang builtins to respect strict FP or not. But it has nothing to do with this patch.

clang/lib/CodeGen/CGBuiltin.cpp
12268

Maybe better to move it into these Emit* functions?

14093

It can't go here because of line 14037. But the comment seems good here.

pengfei added inline comments.Sun, Jan 17, 5:02 PM
clang/test/CodeGen/X86/avx512dq-builtins-constrained.c
3

Where is the file used? It results in failure on Windows.