[cfe-commits] [PATCH] Add -fobjc-direct-class-refs

[Jonathan Schleifer]

Am 14.05.2012 um 21:12 schrieb John McCall:

> I agree that this is at least theoretically independent of the fragile ABI vs. the nonfragile ABI, although I suspect that you'd need to check both implementations to verify that they do, in fact, guarantee the correctness of this.

Well, not only theoretically: The GNUstep runtime uses the non-fragile ABI, while my runtime currently uses the fragile ABI (I wanted to be compatible to GCC and didn't have the time yet).

What I do is that in the configure of my runtime I check if -fobjc-direct-class-refs is accepted by Clang and if so use it and then later output it when the runtime is queried for the OBJCFLAGS to compile with.

> In Darwin's runtime, at least, the nonfragile ABI reserves the right to make class references "forward", so that the address of the global symbol is not necessarily the address of the class.

Yes, but should this really be tied to the non-fragile ABI? IMHO even a ABI version would make more sense than saying "non-fragile ABI also means direct class references". This would also mean that we break existing stuff: Currently, the non-fragile ABI does not emit direct-class refs. If it suddenly would, I'm sure stuff will break.

> Or, you know, it could be a subclass that just implements GetClass differently, or even just sets a flag in the common GNU implementation that is honored by GetClass.  There is no need to leap to the most absurd possible implementation.
> 
> The right thing to do is to propagate information down like "please optimize for this specific runtime".  Whether that means "-fgnustep-runtime" or "-fgnu-runtime=gnustep" or "-foptimize-runtime=gnustep" is a separable choice.

We would also need to specify the version, as an old version of the runtime can be lacking a feature.

> There is a separate structure called the CodeGenOptions which carries options which don't alter the language dialect but which do impact how code is emitted to implement it.

Ok, I will look into moving it there. I still don't see a reason why this shouldn't be a separate flag, so I'm still hoping of being able to get that in. I'd like to have a solution for my users where they don't have to recompile Clang or as a hack build some LLVM optimization module that replaces it (especially since last time I tried -emit-llvm, stuff would just crash).

So, what I'm looking for is a solution that could get upstream and won't require the user to do anything, so that my configure could just check if Clang supports it and if so use it.

--
Jonathan