rjmccall added a comment. In D76077#1921490 <https://reviews.llvm.org/D76077#1921490>, @LukeGeeson wrote:
> In D76077#1919861 <https://reviews.llvm.org/D76077#1919861>, @rjmccall wrote: > > > I don't understand why you wouldn't add a new IR type for this; doing so > > should be totally mechanical. > > > We had a few reasons for doing it this way. > > By adding a new IR type we would need to consider calling conventions, and IR > optimizations for what is essentially an opaque storage-only type. IR optimizations should just fall out; the code in `APFloat` should work for arbitrary FP semantics. Calling something a "storage-only" type does not get you out of worrying about calling conventions at the ABI level. You can forbid passing your type as an argument or result directly, but structs containing your type as a field can still be passed around, and the behavior for that needs to be defined. > Bfloat has no soft ABI, and all the supported operations can be handled > through intrinsics (in a later patch, removed here due to bloat). If we were > to add a new IR type, then we would need to handle many operations which > would extend beyond what the type is supported for. For instance in GCC we > had to add a new mode in RTL to handle inline memcopy. I don't know why having a soft ABI makes a difference. If the type only works on certain platforms, then it can't be used on other platforms. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76077/new/ https://reviews.llvm.org/D76077 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
