RE: [PATCH] D36501: add flag to undo ABI change in r310401
Paul: is the PS4 toolchain's ABI based on that of a particular Clang release, or is it a branch from trunk at some point? Or something else? (And which release / revision?) I am reminded that there are two parts to the ABI, the C++ part and the platform part. PS4's C++ ABI is whatever Clang 3.2 did; the platform part is AMD64 (as of LLVM 3.2) with (IIRC) a couple minor differences. Whenever there is an ABI change (that we notice), we go through an exercise to determine whether it's benign or we have to undo it. Games built with a 3.2-based toolchain must be runnable on OS/middleware built with all subsequent versions. It is never the case that a game built with version N must be runnable on an OS built with version N-1, if that helps. --paulr ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D36501: add flag to undo ABI change in r310401
> On Aug 24, 2017, at 3:48 PM, Richard Smith wrote: > On 24 August 2017 at 12:24, Paul Robinson via Phabricator via cfe-commits > mailto:cfe-commits@lists.llvm.org>> wrote: > probinson added a comment. > > Locally we have a couple different tactics for dealing with changes that we > can't support. A more coherent approach would be great. > For example we defined a new TargetCXXABI::Kind value that is mostly > GenericItaniumABI except where it isn't. > I personally did not do most of the various ABI-related tweaks so I don't > claim to have a good handle on them, and we have been slow to get these > things upstream; but I'd love to make that happen. > > I'm looking into adding a more general mechanism to request ABI (bug) > compatibility with a prior version of Clang. > > Paul: is the PS4 toolchain's ABI based on that of a particular Clang release, > or is it a branch from trunk at some point? Or something else? (And which > release / revision?) > > John: X86_64ABIInfo::classifyIntegerMMXAsSSE() has a special case for Darwin > OSes for compatibility with older Clang compilers; likewise for > X86_64ABIInfo::honorsRevision0_98(). Is this a case of wanting compatibility > with an older version of Clang by default when targeting Darwin, or is it > just the case that the platform ABI is different for that target (where the > historical reason for the different choice in the platform ABI was a bug in > older versions of Clang)? The latter. There was a bug, and we decided that we weren't allowed to fix it, so it's the ABI now. Note that there's no way to override the default. John. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D36501: add flag to undo ABI change in r310401
On 24 August 2017 at 12:24, Paul Robinson via Phabricator via cfe-commits < cfe-commits@lists.llvm.org> wrote: > probinson added a comment. > > Locally we have a couple different tactics for dealing with changes that > we can't support. A more coherent approach would be great. > For example we defined a new TargetCXXABI::Kind value that is mostly > GenericItaniumABI except where it isn't. > I personally did not do most of the various ABI-related tweaks so I don't > claim to have a good handle on them, and we have been slow to get these > things upstream; but I'd love to make that happen. I'm looking into adding a more general mechanism to request ABI (bug) compatibility with a prior version of Clang. Paul: is the PS4 toolchain's ABI based on that of a particular Clang release, or is it a branch from trunk at some point? Or something else? (And which release / revision?) John: X86_64ABIInfo::classifyIntegerMMXAsSSE() has a special case for Darwin OSes for compatibility with older Clang compilers; likewise for X86_64ABIInfo::honorsRevision0_98(). Is this a case of wanting compatibility with an older version of Clang by default when targeting Darwin, or is it just the case that the platform ABI is different for that target (where the historical reason for the different choice in the platform ABI was a bug in older versions of Clang)? ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits