[llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Alberto Barbaro via llvm-dev

Hello dev,

 

I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks!

 

 

 

Regards,

Yan


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Alberto Barbaro via llvm-dev


On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote:

Hello dev,

 

I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks!

The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math.

 -Hal

 

 

 

Regards,

Yan


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Alberto Barbaro via llvm-dev

Hal,

 

Thanks for the reply. I am trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right?

 

 

Thanks,

Yan

 

From: Finkel, Hal J. [mailto:[hidden email]]
Sent: Tuesday, December 4, 2018 11:34 AM
To: Yan Luo <[hidden email]>; [hidden email]
Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

 

 

On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote:

Hello dev,

 

I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks!

The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math.

 -Hal

 

 

 

Regards,

Yan



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Alberto Barbaro via llvm-dev
On 12/4/18 3:28 PM, Yan Luo wrote:

Hal,

 

Thanks for the reply. I am trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right?

That may have been true. In recent times, we have per-instruction fast-math attributes, so the unsafe-fp-math setting isn't the controlling factor.

 -Hal

 

 

Thanks,

Yan

 

From: Finkel, Hal J. [[hidden email]]
Sent: Tuesday, December 4, 2018 11:34 AM
To: Yan Luo [hidden email]; [hidden email]
Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

 

 

On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote:

Hello dev,

 

I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks!

The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math.

 -Hal

 

 

 

Regards,

Yan



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

Alberto Barbaro via llvm-dev

Thanks!

 

From: Finkel, Hal J. [mailto:[hidden email]]
Sent: Tuesday, December 4, 2018 1:44 PM
To: Yan Luo <[hidden email]>; [hidden email]
Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

 

On 12/4/18 3:28 PM, Yan Luo wrote:

Hal,

 

Thanks for the reply. I am trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right?

That may have been true. In recent times, we have per-instruction fast-math attributes, so the unsafe-fp-math setting isn't the controlling factor.

 -Hal

 

 

Thanks,

Yan

 

From: Finkel, Hal J. [[hidden email]]
Sent: Tuesday, December 4, 2018 11:34 AM
To: Yan Luo [hidden email]; [hidden email]
Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining

 

 

On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote:

Hello dev,

 

I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks!

The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math.

 -Hal

 

 

 

Regards,

Yan




_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev