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

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D152798#4417039 <https://reviews.llvm.org/D152798#4417039>, @foad wrote:

> In D152798#4417027 <https://reviews.llvm.org/D152798#4417027>, @nikic wrote:
>
>> Just to give an obvious counter-example: Load-like intrinsics tend to produce poison (because there might be poison in memory).
>
> I was wondering about that case myself. I don't see the benefit of saying that a load-like intrinsic can return poison, unless the compiler recognizes it as a load well enough to do things like forwarding a previously stored value through it.

Not sure I follow. Do you want to define your load intrinsics are performing an implicit freeze? You could do that, but I'm not sure it is desirable.



================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:6419
+      case Intrinsic::amdgcn_wqm:
+      case Intrinsic::amdgcn_wwm:
         return false;
----------------
arsenm wrote:
> arsenm wrote:
> > Bunch more could be handled (I can’t name one that shouldn’t)
> amdgcn_log, amdgcn_fmad_ftz,  int_amdgcn_mul_i24,  int_amdgcn_mul_u24,  int_amdgcn_mulhi_i24,  int_amdgcn_mulhi_u24, int_amdgcn_inverse_ballot, int_amdgcn_ballot,  int_amdgcn_cvt_pk_u8_f32,  int_amdgcn_mqsad_u32_u8,  int_amdgcn_mqsad_pk_u16_u8,  int_amdgcn_qsad_pk_u16_u8, int_amdgcn_sad_u16,  int_amdgcn_sad_hi_u8,  int_amdgcn_msad_u8,  int_amdgcn_sad_u8, f int_amdgcn_lerp,  int_amdgcn_sbfe, int_amdgcn_ubfe,  int_amdgcn_mov_dpp, int_amdgcn_update_dpp, int_amdgcn_ds_permute,  int_amdgcn_ds_bpermute,  int_amdgcn_perm,  int_amdgcn_permlane16, int_amdgcn_permlanex16,  int_amdgcn_mov_dpp8, int_amdgcn_s_get_waveid_in_workgroup, int_amdgcn_permlane64, int_amdgcn_fdot2,  int_amdgcn_fdot2_f16_f16, int_amdgcn_fdot2_bf16_bf16, int_amdgcn_fdot2_f32_bf16, int_amdgcn_sdot2, int_amdgcn_udot2, int_amdgcn_sdot4, int_amdgcn_udot4,  int_amdgcn_sudot4, int_amdgcn_udot8,  int_amdgcn_sudot8
> 
> All the MFMA, there are a bunch more cvt*
> 
> int_amdgcn_fdiv_fast
If you want to add //that// many intrinsics, it's probably better to add a new intrinsic property to the TableGen intrinsic definitions. That should also make it easier to see how complete the coverage is. (Easiest way to do that is probably a new function attribute.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152798