[PATCH] D114766: If constrained intrinsic is replaced, remove its side effect

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

In D114766#3161749 <https://reviews.llvm.org/D114766#3161749>, @lebedev.ri wrote:

> In D114766#3161737 <https://reviews.llvm.org/D114766#3161737>, @sepavloff wrote:
>
>> In D114766#3161688 <https://reviews.llvm.org/D114766#3161688>, @kpn wrote:
>>
>>> In D114766#3161680 <https://reviews.llvm.org/D114766#3161680>, @sepavloff wrote:
>>>
>>>> Moving this logic to `wouldInstructionBeTriviallyDead()` does not seem right, because the decision about removing side effect comes from constant evaluation and not from the state of call object.
>>>
>>> I'm sympathetic to this argument. If a transformation pass determines that a constrained intrinsic can be removed then it would be helpful if that pass could note that fact. This doesn't help us with analysis passes, though. And I'm a little worried about having to explicitly mark constrained intrinsics as removable since I don't know that we do that for any other instruction. If constrained intrinsics are the only time we do this then it seems error prone. Maybe I'm wrong?
>>
>> The ability to remove side effect is vital for the implementation of floating point arithmetic. There are several possible optimization techniques, which depend on this possibility. For example, if FP operations in a function have attributes "round.dynamic" and "fpexcept.ignore" and we know that rounding mode is not changed in this function, we could remove side effect of all the operations, which can give performance of non-constrained operations. As we cannot mix ordinary and constrained operation in the same function, the only way is to control side effect.
>
> We aren't saying that the ocean isn't full of water, we are only saying that you are looking at the pond while thinking it's an ocean.
> We are talking about different things here. Fixing InstSimplify pass will not do any good, because it's effectively not used.

It is used and does its job, as experiments demonstrate. Probably it is not the right place, but until we didn't met its limitations or elaborate a better way we could use this imperfect solution. Moving with small steps toward the perfect implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114766