Move the PowerPC/PPCMergeStringPool work to initializer

[scui-ibm]

Currently, the PPCMergeStringPool merges the global variable after the AsmPrinter initializer adds the global variables to its symbol list. This is to move the merging work of PPCMergeStringPool to its initializer, just like what GlobalMerge does, to avoid adding merged global variables to the AsmPrinter symbol lis.  

[scui-ibm]

gentle ping - any comments/approval?

[stefanp-ibm]

I understand that on AIX in order to have the correct alignment for a particular csect we need to have the global defined in the Initialization phase instead of the Run phase. Is this the issue that we are trying to solve here? Or, am I missing another issue with deleting Globals after Initialization?

Is it not possible to fix this for the AIX AsmPrinter instead of having to force all of the passes to make all of their changes to Globals in the Initialization phase? I feel like going forward there may be problems especially with Target Independent passes.

[stefanp-ibm]

Alignment change for ModuleStringPool csect. I assume that this is the problem you are trying to fix.

[scui-ibm]

I understand that on AIX in order to have the correct alignment for a particular csect we need to have the global defined in the Initialization phase instead of the Run phase. Is this the issue that we are trying to solve here? Or, am I missing another issue with deleting Globals after Initialization?

Thanks Stefan for the comments. Actually, the code change is to fix one of our customer problems. The problem is when AsmPrinter pass run is trying to find the csect of a symbol, the compiler emits an error as the symbol is already merged/removed by PPCMergeStringPool.  The change of #77364 is for the same customer problem, and with that change the compiler error still occurs. As the symbol merged is already added to the symbol table during doInitilization of AsmPrinter (but before PPCMergeStringPool).  We can also fix this during AsmPrinter run, but I believe it’s cleaner with current change – we don’t need to worry about the uses of symbol table of the AsmPrinter for the removed symbols.

Is it not possible to fix this for the AIX AsmPrinter instead of having to force all of the passes to make all of their changes to Globals in the Initialization phase? I feel like going forward there may be problems especially with Target Independent passes.

I’m not that familiar with all the llc passes, but I checked all the doInitilization function of those passes and I couldn’t think of potential issues with this change based on my understanding. Do you have any idea of potential problems with this change?

[stefanp-ibm]

I understand that on AIX in order to have the correct alignment for a particular csect we need to have the global defined in the Initialization phase instead of the Run phase. Is this the issue that we are trying to solve here? Or, am I missing another issue with deleting Globals after Initialization?

Thanks Stefan for the comments. Actually, the code change is to fix one of our customer problems. The problem is when AsmPrinter pass run is trying to find the csect of a symbol, the compiler emits an error as the symbol is already merged/removed by PPCMergeStringPool. The change of #77364 is for the same customer problem, and with that change the compiler error still occurs. As the symbol merged is already added to the symbol table during doInitilization of AsmPrinter (but before PPCMergeStringPool). We can also fix this during AsmPrinter run, but I believe it’s cleaner with current change – we don’t need to worry about the uses of symbol table of the AsmPrinter for the removed symbols.

Is it not possible to fix this for the AIX AsmPrinter instead of having to force all of the passes to make all of their changes to Globals in the Initialization phase? I feel like going forward there may be problems especially with Target Independent passes.

I’m not that familiar with all the llc passes, but I checked all the doInitilization function of those passes and I couldn’t think of potential issues with this change based on my understanding. Do you have any idea of potential problems with this change?

Okay, that's fair. I'm also not aware of existing problems with this. I'm not actually concerned about this patch as much as the design that requires us to move passes that modify globals into the init stage. I'm not going to block this patch.

[stefanp-ibm]

LGTM