Ensure that the DSO Locality of the globals in the IR is derived from their final visibility when using -fvisibility-from-dllstorageclass.
Details
Diff Detail
Event Timeline
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.