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.
Details
- Reviewers
• tstellarAMD bogner efriedma
Diff Detail
Event Timeline
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).
Err, actually that's wrong; we do ensure that intrinsics have the right attributes. So I guess this is okay as-is.
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).