[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-21 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment. In D115804#3202479 , @sepavloff wrote: > In D115804#3201681 , @spatel wrote: > >> In D115804#3201044 , @craig.topper >> wrote: >> >>> What's the plan

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-20 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added a comment. In D115804#3201681 , @spatel wrote: > In D115804#3201044 , @craig.topper > wrote: > >> What's the plan for constrained intrinsics versions of these intrinsics? The >> IRBuilder calls f

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-19 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added subscribers: kpn, sepavloff, andrew.w.kaylor. spatel added a comment. In D115804#3201044 , @craig.topper wrote: > What's the plan for constrained intrinsics versions of these intrinsics? The > IRBuilder calls for CreateFPToSI and CreateFPTo

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-17 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment. What's the plan for constrained intrinsics versions of these intrinsics? The IRBuilder calls for CreateFPToSI and CreateFPToUI are strict FP aware, but this new code isn't. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-16 Thread Sanjay Patel via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8c7f2a4f8719: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast… (authored by spatel). Herald added a project: clang. Chan

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-16 Thread Nikita Popov via Phabricator via cfe-commits
nikic accepted this revision. nikic added a comment. This revision is now accepted and ready to land. LGTM In D115804#3195158 , @spatel wrote: > In D115804#3195002 , @nikic wrote: > >> Looks reasonable. Making fl

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-15 Thread Juneyoung Lee via Phabricator via cfe-commits
aqjune added a comment. This sounds like a great fix to me! :) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115804/new/ https://reviews.llvm.org/D115804 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/m

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-15 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added a comment. In D115804#3195002 , @nikic wrote: > Looks reasonable. Making float to int cast well defined is exactly why these > intrinsics exist. Should we also drop the "string-float-cast-overflow" > attribute, as UB is now prevented in a d

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-15 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment. Looks reasonable. Making float to int cast well defined is exactly why these intrinsics exist. Should we also drop the "string-float-cast-overflow" attribute, as UB is now prevented in a different way? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115804/new/ ht

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

2021-12-15 Thread Sanjay Patel via Phabricator via cfe-commits
spatel created this revision. spatel added reviewers: MatzeB, neildhar, nikic, aqjune, dmgreen. Herald added a subscriber: mcrosier. spatel requested review of this revision. We got an unintended consequence of the optimizer getting smarter when compiling in a non-standard mode, and there's no go