Ensure that the DSO Locality of the globals in the IR is derived from their final visibility when using -fvisibility-from-dllstorageclass.
Im not sure if renaming the check prefix is actually helpful, but sure. This does seem like somewhat unfortunate. For the dllexport case, you really want dso_local. define dso_local global and declare dso_local global are preferable in this case as that guarantees a local definition, which is always the case for an exported symbol. You definitely do not want declare extern dso_local global. A few of the changes here are actually changing the IRGen from the desired state, is that intentional?
Thanks for looking at this. Yes, overriding the IRGen pessimistically was my intention. -fvisibility-from-dllstorageclass is supposed to override the effects of visibility options and annotations - and those can have an effect on the DSO locality. I had also thought that anyone deploying this option is probably in a similar circumstance to us where they have a file format that deviates somewhat from the expected rules. Therefore, setting DSO locality pessimistically and fixing things up in the linker makes sense. Having said that I can also see an argument for leaving the DSO locality as it is. Do you think it would be better to put this behaviour on a switch? It can be off by default but the PS4 driver can set it on?
I'm not convinced that making this an option is valuable at this time. Right now, I don't think that this functionality is broadly adopted, and, I suppose that if your linker is clever enough to perform optimizations thoroughly enough, it wouldn't matter too much (modulo link time explosion). I would like to see this more accurately explained in the documentation though - CodeGenModule.cpp L423-L424 would be a good site for that. Beyond that, LGTM.