This is an archive of the discontinued LLVM Phabricator instance.

DAG: Ignore call site attributes when emitting target intrinsic
ClosedPublic

Authored by arsenm on Nov 15 2016, 4:38 PM.

Details

Summary

A target intrinsic may be defined as possibly reading memory,
but the call site may have additional knowledge that it doesn't read
memory. The intrinsic lowering will expect the pessimistic
assumption of the intrinsic definition, so the chain should
still be used.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 78097.Nov 15 2016, 4:38 PM
arsenm retitled this revision from to DAG: Ignore call site attributes when emitting target intrinsic.
arsenm updated this object.
arsenm added a reviewer: bogner.
arsenm added a subscriber: llvm-commits.
efriedma requested changes to this revision.Nov 16 2016, 10:31 AM
efriedma added a reviewer: efriedma.
efriedma added a subscriber: efriedma.

Why can't you just compute whether the intrinsic has a chain based on the IntrinsicInfo? Checking for a readnone attribute in the IR seems dubious at best; an intrinsic can be both readnone and require a chain (for example, it could have undefined behavior for some inputs).

This revision now requires changes to proceed.Nov 16 2016, 10:31 AM

Why can't you just compute whether the intrinsic has a chain based on the IntrinsicInfo? Checking for a readnone attribute in the IR seems dubious at best; an intrinsic can be both readnone and require a chain (for example, it could have undefined behavior for some inputs).

For what exactly are you asking? We can call getTgtMemIntrinsic, but the fall-back behavior would be the same (unless you want this to be a large behavioral change). The UB issue is potentially important, if we have readonly/readnone target intrinsics with UB, but that seems like a pre-existing issue.

llvm.sqrt is a readnone intrinsic which can exhibit undefined behavior, but I think we don't actually generate a chain for it at the moment, so maybe we can get away with querying whether the intrinsic is readnone. But the right way to do that is to call Intrinsic::getAttributes; we can't trust the IR to have the right attributes on the declaration (it's not something the verifier checks).

efriedma accepted this revision.Nov 21 2016, 11:56 AM
efriedma edited edge metadata.

Err, actually that's wrong; we do ensure that intrinsics have the right attributes. So I guess this is okay as-is.

This revision is now accepted and ready to land.Nov 21 2016, 11:56 AM

Why can't you just compute whether the intrinsic has a chain based on the IntrinsicInfo? Checking for a readnone attribute in the IR seems dubious at best; an intrinsic can be both readnone and require a chain (for example, it could have undefined behavior for some inputs).

llvm.sqrt is a readnone intrinsic which can exhibit undefined behavior, but I think we don't actually generate a chain for it at the moment, so maybe we can get away with querying whether the intrinsic is readnone. But the right way to do that is to call Intrinsic::getAttributes; we can't trust the IR to have the right attributes on the declaration (it's not something the verifier checks).

Intrinsic declarations do have the right attributes on the declaration. The Function constructor ensures they are added.

Why can't you just compute whether the intrinsic has a chain based on the IntrinsicInfo? Checking for a readnone attribute in the IR seems dubious at best; an intrinsic can be both readnone and require a chain (for example, it could have undefined behavior for some inputs).

llvm.sqrt is a readnone intrinsic which can exhibit undefined behavior, but I think we don't actually generate a chain for it at the moment, so maybe we can get away with querying whether the intrinsic is readnone. But the right way to do that is to call Intrinsic::getAttributes; we can't trust the IR to have the right attributes on the declaration (it's not something the verifier checks).

Intrinsic declarations do have the right attributes on the declaration. The Function constructor ensures they are added.

As a special case,you can have intrinsics defined in the backend which are just generally broken right now. The TargetIntrinsicInfo interface does exist to fix this, but needs work to make actually usable (and probably not worth the effort).

arsenm closed this revision.Nov 21 2016, 3:06 PM

r287593