Yeah, this happens because a single AMOVD becomes two real instructions so there's not really a stage where this can be fixed in the current way of working. I guess the move needs to be decomposed earlier.

I think a similar issue affects ARM64 (and probably the other fixed-width instruction architectures).

Did this very thing on Sparc decades ago; the inner loop of fpppp (which was huge) had 42 different "base registers" which was of course far more than the number of registers.

I'd like to push this off until 1.9. Note that this is problem occurs on other architectures, not just PPC.

OK, so do you want the title changed?

That would be fine. Any architecture with load/store instructions using a register + small immediate to form the address is eligible for this optimization. I suspect it might need linker or at least assembler assistance, since we'll be emitting relocations along the lines of

  base := &global1
  x := *(base + (&global2-&global1))

and we'd want to usually guess right at the rough magnitude of the difference of those two globals.

Where this problem shows up most often is when referencing constants, which is common in many of functions in the math package. It seems that with constants, they should all be in rodata, and then the base could be the start of the rodata (named: runtime.rodata). Then the offset of the constant from the start of rodata would be known at compile time.

Likewise something similar could be done for static data.

@dr2chase I'd like to try and look at this further and try to get it working. If you have some clues or pointers that would be helpful.

• I can see that linker assistance is needed but not sure how to do that.
• I see that the base register needs to be split from the load of the constant because now they are always done together, but where does that need to be done so that common base registers can be recognized.
  Any help appreciated...

Change https://golang.org/cl/68250 mentions this issue: cmd/compile: don't fold address of global into load/store on PPC64

@cherrymui @jeremyfaller Will there be support in the new linker to fix this problem? It still exists, mostly in the math package.

Here's an example of some code from math.sin. R31 is reloaded with the same value over and over.

                x = Sin(Pi * (x - 2))
  0x94cb4               3fe0001b                ADDIS $0,$27,R31                     // lis r31,27              
  0x94cb8               c85fba90                LFD -17776(R31),F2                   // lfd f2,-17776(r31)      
  0x94cbc               fc211028                FSUB F1,F2,F1                        // fsub f1,f1,f2           
  0x94cc0               3fe0001b                ADDIS $0,$27,R31                     // lis r31,27              
  0x94cc4               c85fbaf8                LFD -17672(R31),F2                   // lfd f2,-17672(r31)      
  0x94cc8               fc2100b2                FMUL F1,F2,F1                        // fmul f1,f1,f2           
  0x94ccc               d8210020                STFD 32(R1),F1                       // stfd f1,32(r1)          
  0x94cd0               480027f1                CALL math.Sin(SB)                    // bl 0x974c0              
  0x94cd4               c8210028                LFD 40(R1),F1                        // lfd f1,40(r1)           
        return -x
  0x94cd8               fc200850                FNEG F1,F1                           // fneg f1,f1      
  0x94cdc               d8210060                STFD 96(R1),F1                       // stfd f1,96(r1)  
  0x94ce0               ebe10000                MOVD 0(R1),R31                       // ld r31,0(r1)    
  0x94ce4               7fe803a6                MOVD R31,LR                          // mtlr r31        
  0x94ce8               38210038                ADD R1,$56,R1                        // addi r1,r1,56   
  0x94cec               4e800020                RET                                  // bclr 20,lt,0    
                x = Cos(Pi * (0.5 - x))
  0x94cf0               3fe0001b                ADDIS $0,$27,R31                     // lis r31,27              
  0x94cf4               c85fb8e0                LFD -18208(R31),F2                   // lfd f2,-18208(r31)      
  0x94cf8               fc220828                FSUB F2,F1,F1                        // fsub f1,f2,f1           
  0x94cfc               3fe0001b                ADDIS $0,$27,R31                     // lis r31,27              
  0x94d00               c85fbaf8                LFD -17672(R31),F2                   // lfd f2,-17672(r31)      
  0x94d04               fc2100b2                FMUL F1,F2,F1                        // fmul f1,f1,f2           
  0x94d08               d8210020                STFD 32(R1),F1                       // stfd f1,32(r1)          
  0x94d0c               480027d5                CALL math.Cos(SB)                    // bl 0x974e0              
  0x94d10               c8210028                LFD 40(R1),F1                        // lfd f1,40(r1)           
  0x94d14               4bffffc4                BR 0x94cd8                           // b 0x94cd8               
                x = Sin(Pi * x)
  0x94d18               3fe0001b                ADDIS $0,$27,R31                     // lis r31,27              
  0x94d1c               c85fbaf8                LFD -17672(R31),F2                   // lfd f2,-17672(r31)      
  0x94d20               fc2100b2                FMUL F1,F2,F1                        // fmul f1,f1,f2           
  0x94d24               d8210020                STFD 32(R1),F1                       // stfd f1,32(r1)          
  0x94d28               48002799                CALL math.Sin(SB)                    // bl 0x974c0              
  0x94d2c               c8210028                LFD 40(R1),F1                        // lfd f1,40(r1)           
  0x94d30               4bffffa8                BR 0x94cd8                           // b 0x94cd8               

I don't think the new linker does anything with this. This is all in the compiler.

I wonder if marking global address (i.e. a MOVDaddr with the operand being SB) not rematerializeable helps. If we do that, the register allocator will try to keep the address in a register, instead of rematerialize it each time. It doesn't last across a call, though.

There are two problems here that I am aware of.

First, when loading a constant or static variable, the base address is always generated using 2 instructions in asm9.go. The relocated value for the upper part of the base address is loaded into r31 (temp register) then added into the relocated value for the lower part of the base address. Because it is done this way, the register allocator is not able to find the first value (in r31) in common, even though it frequently is reloading the same value over and over. This could be split out into 2 instructions in obj9.go (or elsewhere?) and I would be willing to experiment with this.

The second problem is that these values are created as relocated values relative to the constant or static variable. The actual values aren't known until link time and I don't think they really look like the same value to the register allocator so it wouldn't know they are the same even if it had the information to try.

We would need to do something like David Chase mentions in his post on Nov. 2016. Maybe I'm jumping to conclusions, but I thought maybe since it looks like a TOC is now always being generated that would help this problem. I thought all addresses of this type would be in the TOC and the offset within the TOC would be known so that the same base could be used when referencing them. Or maybe I'm making some incorrect assumptions on how this works.

I agree - we'll need to put all the constants together in a group (or groups, if there are too many?), add an SSA instruction to get the base of that group, and have each constant load be an offset from its group base.

There's no PC-relative load in powerpc? That would make life much easier.

This is a place where a globally reserved SB register can be useful. Maybe we could do that now with the internal ABI.

There's no PC-relative load in powerpc? That would make life much easier.

There is not, but I'm not actually sure it would help. cmd/compile has code to maintain R2 as a TOC pointer (it's needed for shared libraries) which could be globally enabled but the load instructions only have a 16 bit displacement and I don't think you know enough at this point of codegen to know if the base value can be shared between two loads?

Power10 has PC relative loads and that seems to improve this. This problem has been around for a while and for < Power10 there doesn't seem to be a nice solution so I think this could be closed.