RE: [PATCH] D36501: add flag to undo ABI change in r310401

[Robinson, Paul via cfe-commits]

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

[John McCall via cfe-commits]

> 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 
> > 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

[Richard Smith via cfe-commits]

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