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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
