jdoerfert added a comment. In D74387#1967289 <https://reviews.llvm.org/D74387#1967289>, @Fznamznon wrote:
> In D74387#1965634 <https://reviews.llvm.org/D74387#1965634>, @jdoerfert wrote: > > > In D74387#1964483 <https://reviews.llvm.org/D74387#1964483>, @Fznamznon > > wrote: > > > > > In D74387#1950593 <https://reviews.llvm.org/D74387#1950593>, @jdoerfert > > > wrote: > > > > > > > This is needed for OpenMP as well. Does it make sense to include it in > > > > this patch or in another one? > > > > > > > > > I thought OpenMP already has diagnostics for unsupported types (at least > > > looking into this commit > > > https://github.com/llvm/llvm-project/commit/123ad1969171d0b22d0c5d0ec23468586c4d8fa7). > > > Am I wrong? > > > The diagnostic which I'm implementing here is stricter than existing > > > OpenMP diagnostic, the main goal is do not emit unsupported type at all. > > > Does OpenMP need such restriction as well? > > > > > > OpenMP handling needs to be reverted/redone: > > > > 1. If no aux triple is available it just crashes. > > 2. If the unavailable type is not used in one of the pattern matched > > expressions it crashes (usually during instruction selection but not > > always). Try a call with long double arguments for example. > > > > I'm not sure this patch fits the bill but what I was thinking we need is > > roughly: If you have a expression with operands or function definition with > > return/argument types which are not supported on the target, mark the > > definition as unavailable with the type note you have. We should especially > > allow members to have unavailable types if the member is not accessed. > > Memcpy like operations (=mapping) are OK though. I think this should be the > > same for OpenMP and Sycl (and HIP, and ...). > > > Why we should allow members to have unavailable types if the member is not > accessed? I don't think that we always can do it, especially for SYCL. Even > if the member is not accessed directly, the whole struct with unavailable > type inside will get into resulting LLVM IR module anyway, this can be a > problem, I guess. On the host you know how large the type is so you can replace it in the device module with a placeholder of the appropriate size. You want to do this (in OpenMP for sure) because things you map might have constitutes you don't want to access on the device but you can also not (easily) split out of your mapped type. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74387/new/ https://reviews.llvm.org/D74387 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits