shiltian wrote: > Agreed. This PR provides a solution to a user request. It is not meant to be > used as a design point: using existing infrastructure/syntax/etc. is > deliberate and the goal is not to set a strategic direction for future more > comprehensive designs.
I can't agree with this, unfortunately. Once something is merged, people (no matter who is working on LLVM or the different levels of end users) will start following the existing code, use it as justification, and build on top of it. That makes future cleanup and better design even harder. > This was intentional as > [requested](https://github.com/AMD-Lightning-Internal/llvm-project/pull/4213#discussion_r2387697672) > by @Pierre-vh: I don't think the backend is a good place for this. Clang has a much better and cleaner error-handling mechanism than the backend. The backend will likely end up emitting errors like "some intrinsics can't be selected", which would be very confusing for someone outside of LLVM world. IMO, Clang builtins are high-level user-facing, so we should make them robust instead of pushing the responsibility onto users or lower levels in the pipeline. https://github.com/llvm/llvm-project/pull/172090 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
