[PATCH] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

In D99675#2695480 <https://reviews.llvm.org/D99675#2695480>, @mibintc wrote:

> In D99675#2695424 <https://reviews.llvm.org/D99675#2695424>, @kpn wrote:
>
>> What changes are needed for a backend, and what happens if they aren't done?
>
> In the clang patch, I'm planning to add into TargetInfo a function like "does the target support __arithmetic_fence"?
> In the llvm patch, the fallback implementation could be to merely ignore the call, and pass through the operand value. Is that adequate?

If clang is the only compiler to ever emit this new intrinsic then, yes, that's perfectly fine.

If a front-end other than clang uses the new fence then I'm nervous about having the fence just vanish. If the fence is used then it must be for correctness, right? Having something needed for correctness silently not work seems ... sub-optimal. It's the sort of thing that might not get caught in testing, and then you've got end-users running software that silently lacks something needed for correctness. That makes me nervous. I'd rather LLVM bomb instead of silently dropping this fence. Then developers know they have a problem before a product goes out the door.

But if I'm the only one that's nervous then that's OK and clang rejecting the compile would be sufficient.

Has this sort of issue come up in the past? How was it handled?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99675/new/

https://reviews.llvm.org/D99675