[PATCH] D152798: [AMDGPU][ValueTracking] Handle amdgcn intrinsics that cannot create poison

[Jay Foad via Phabricator via llvm-commits]

foad added a comment.

I'd appreciate some confirmation that this makes sense, for some or all of the cases. Here's my thinking:

  case Intrinsic::amdgcn_fmed3:
  case Intrinsic::amdgcn_fmul_legacy:
  case Intrinsic::amdgcn_fract:
  case Intrinsic::amdgcn_rcp:
  case Intrinsic::amdgcn_rsq:

These are just standard arithmetic operations, so should be handled the same as generic arithmetic intrinsics like maxnum.

  case Intrinsic::amdgcn_icmp:

This is like ballot, a convergent operation that depends on values in other lanes.

  case Intrinsic::amdgcn_interp_p1:
  case Intrinsic::amdgcn_interp_p1_f16:
  case Intrinsic::amdgcn_interp_p2:
  case Intrinsic::amdgcn_interp_p2_f16:

These ones load values from LDS as well as doing arithmetic, but we don't expose the load to the compiler so I don't think there's any reason to say that the loaded value could be poison.

  case Intrinsic::amdgcn_mbcnt_hi:
  case Intrinsic::amdgcn_mbcnt_lo:

The result of these depends on the lane ID of the executing lane.

  case Intrinsic::amdgcn_readfirstlane:
  case Intrinsic::amdgcn_readlane:

These depend on values from other lanes. For readlane we //could// define that the result is poison if the lane number argument is out of range, but AFAIK we do not do that - the spec is just that you get whatever the corresponding hardware instruction would return, and hardware instructions never return poison.

  case Intrinsic::amdgcn_softwqm:
  case Intrinsic::amdgcn_wqm:
  case Intrinsic::amdgcn_wwm:

These ones return the input value unmodified.

In summary, for the intrinsics whose results depend on some extra state, there is no point in saying that that state could be poison, unless it is exposed as a regular IR value that the compiler can reason about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152798