AlexVlx wrote: > Mechanically, this pass can be replaced with trivial handling of the > intrinsic in AMDGPUInstCombineIntrinsic; we don't need a new module pass. As > inserted into the pipeline here, this does not have any advantage over > handling it directly in instcombine.
Perhaps, except the pass is not just for wavesize, but rather will soon gain a bunch of additional tasks, and instcombine runs later and is dependent on optimisation level. The latter two aspects are not the end of the world, but also by the by. > > > We could just turn this off for a particular compilation and maintain the > > current unfoldable state. > > This violates the fundamental principles of a modular compiler IR. Any > mechanism which we would have to invent to stop this fold from happening in a > specific bitcode library build will be quite unsavory, and require > handholding of every user to not run into the same issue. I'd like to > systematically avoid this class problem by having a separate library build. I keep not really following the point you are trying to make here: is it that you are worried about the very specific case of libc doing a thing, or is it "every user". Every user does not build like either of those, because the current `generic` target you get absent an mcpu is not super useful, or even particularly documented. I'm not sure why you have to speculate about imaginary mechanisms we'd have to invent, considering that we can simply do early out if there's no mcpu/the mcpu is `generic`, within this pass (as it now does). https://github.com/llvm/llvm-project/pull/114481 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
