Allow translation of global internal constants with private address space

[idubinov]

Global constants cannot be processed in SPIRV. This change enables the translation of global constants declared in the private address space into local variables within the functions where they are used

[CLAassistant]

All committers have signed the CLA.

[MrSidims]

Overall LGTM, but I'd like to hear opinion from other reviewers as well.

[MrSidims]

Please also add a scenario, when 2 (or more) internal constant GVs are used within the same function. We want to make sure, that alloca's are placed consequently in the entry basic basic block, preceding any other instruction (including generated by the added code store instructions).
Reason: from https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_logical_layout_of_a_module

All OpVariable instructions in a function must be in the first block in the function. These instructions, together with any intermixed OpLine and OpNoLine instructions, must be the first instructions in that block. (Note the validation rules prevent OpPhi instructions in the first block of a function.)

[idubinov]

done

[MrSidims]

Also, may be a good idea to do this conditionally under a new llvm-spirv option, like "internalize-global-constants", but I don't have a strong opinion on that, defaulting internalization like it's done in the patch should be safe. WDYT @svenvh ?

[svenvh]

Also, may be a good idea to do this conditionally under a new llvm-spirv option, like "internalize-global-constants", but I don't have a strong opinion on that, defaulting internalization like it's done in the patch should be safe. WDYT @svenvh ?

No strong opinion on gating this behind an option; the patch as it is now seems fine to me.