jfb added a comment. In D76077#1921973 <https://reviews.llvm.org/D76077#1921973>, @rjmccall wrote:
> 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. Having an IR type sounds like the right thing to do here. 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
