@cherrymui

For ARM32, I am not sure we want very different mechanisms for this on GOARM=7 or not.
For ARM64, it looks like worth an experiment in Go 1.9.

@minux Right. The linker would have to support R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS if we wanted to support armv7 in its completeness. As for floating-point, vmov (vfpv3) supports a reasonable range of constants.

@benshi001 : you might want to tackle this.

Besides "MOVT $imme16, R", there are also "MOV $imme16, R". both encode the 16-bit immediate into the instruction than constant pool.

Maybe we can all attribute them to "MOVW $imme, R" in the front-end, then auto pick a right form in the back-end among
MOVT $imme16, R
MOV $imme16, R
MOV $imme8<<$imme4, R

I roughly have a solution for dynamically selecting the above 3 forms for MOVW. But it depends on
https://go-review.googlesource.com/#/c/35565/ and https://go-review.googlesource.com/#/c/35610/ ?

Can they be reviewed and accepted first?

I did some benchmark:

BenchmarkF-4   	 3000000	       508 ns/op
BenchmarkG-4   	 2000000	       769 ns/op

where F uses constant pool while G uses MOVW-MOVT.

TEXT ·f(SB),0,$0-4
        MOVW    $100, R0
        MOVW    $0, R5
loop:
        MOVW    $0x12345678, R1 // use constant pool
        ADD     R1, R5
        MOVW    $0x87654321, R2
        ADD     R2, R5
        MOVW    $0xa0b0c0d0, R3
        ADD     R3, R5
        MOVW    $0xd0c0b0a0, R4
        ADD     R4, R5
        SUB     $1, R0
        CMP     $0, R0
        BNE     loop
        MOVW    R5, ret+0(FP)
        RET

TEXT ·g(SB),0,$0-4
        MOVW    $100, R0
        MOVW    $0, R5
loop:
        WORD    $0xe3051678 // MOVW $0x5678, R1
        WORD    $0xe3411234 // MOVT $0x1234, R1
        ADD     R1, R5
        WORD    $0xe3042321 // MOVW $0x4321, R2
        WORD    $0xe3482765 // MOVT $0x8765, R2
        ADD     R2, R5
        WORD    $0xe30c30d0 // MOVW $0xc0d0, R3
        WORD    $0xe34a30b0 // MOVT $0xa0b0, R3
        ADD     R3, R5
        WORD    $0xe30b40a0 // MOVW $0xb0a0, R4
        WORD    $0xe34d40c0 // MOVT $0xd0c0, R4
        ADD     R4, R5
        SUB     $1, R0
        CMP     $0, R0
        BNE     loop
        MOVW    R5, ret+0(FP)
        RET

Also tried a couple of others. Using constant pool seems always faster. So I'm not sure this is worth doing.

If the constant fits in 16 bit, using a single MOVW seems better though.

Yes. I agree. It is worth to

1. substitute
   MOVW $0x1234, R1 // use constant pool
   with
   MOVW $0x1234, R1 // encode 16-bit 0x1234 into the instruction

2. substitute
   MOVW $0x12340000, R1 // use constant pool
   with
   MOVT $0x1234, R1 // encode 16-bit 0x1234 into the instruction

But it not worth substitute
MOVW $0x12345678, R1 // use constant pool
with
MOVT $0x1234, R1
MOVW $0x5678, R1

Thanks for benchmarking.

However, I think it's worth evaluating the movw; movt pair on whole programs. Micro-benchmarks won't show the cache effects that these instructions can potentially mitigate. Moreover, the movw; movt pair is used by both GCC and clang on ARMv7 as the preferred method of 'large' immediate generation, and it's quite likely that those instruction selection decisions were even implemented by ARM employees. It would be at least a little surprising to discover that the conventional wisdom here is wrong.

GCC will compile
extern int q;

void ss(void)
{
q = 0x12345678;
}

to

Disassembly of section .text:

00000000 :
0: e3003000 movw r3, # 0
4: e3403000 movt r3, # 0
8: e3052678 movw r2, # 22136 ; 0x5678
c: e3412234 movt r2, # 4660 ; 0x1234
10: e5832000 str r2, [r3]
14: e12fff1e bx lr

I can understand why a pair of
MOVW, MOVT is more efficient.

Since the constant pool is in the text segment, the CPU has to fill one data cache line to load the constant, which can cost hundreds of ticks.

But for MOVW/MOVT, the immediate is already in the code cache, and only several ticks are cost.

For a trade off,
BenchmarkF-4 3000000 508 ns/op
BenchmarkG-4 2000000 769 ns/op
the cost is tiny compared to load a new cache line.

There is already "VMOV R, # immediate" implemented for encoding short floating point constants into the instruction, at line 2222 - 2231 in cmd/internal/obj/arm/asm5.go

     case 81: /* fmov sfcon,freg */
            o1 = 0x0eb00a00 // VMOV imm 32
            if p.As == AMOVD {
                    o1 = 0xeeb00b00 // VMOV imm 64
            }
            o1 |= ((uint32(p.Scond) & C_SCOND) ^ C_SCOND_XOR) << 28
            o1 |= (uint32(p.To.Reg) & 15) << 12
            v := int32(chipfloat5(ctxt, p.From.Val.(float64)))
            o1 |= (uint32(v) & 0xf) << 0
            o1 |= (uint32(v) & 0xf0) << 12

We need only consider MOVW/MOVT on ARMv7.

This issue becomes more complex.

All sub-forms of MOVW assume the output has fixed length.

But "MOVW $0x12345678, R1" is assembled to 4-byte output on ARMv6, while 8-byte on ARMv7.

How about substitute MOVW.cond $0x00001234, R0 with

MOVW.cond $0x1234, R0
MOVT.cond $0x0000, R0
MOVW.cond R0, R0 (for setting the condition flag bits)

Though 3 bytes are cost, it is still more efficient than fill a new data cache line.

Yes, my benchmark might not be very representative. But my point is that if we do this, we would need to base it on evidence of actual speedup, instead of what appears to be fast. Note that the complexity of the toolchain is also a cost.

But "MOVW $0x12345678, R1" is assembled to 4-byte output on ARMv6, while 8-byte on ARMv7.

You can do this by adding another column, GOARM, in Optab. See cmd/internal/obj/mips/asm0.go, where MIPS32 vs MIPS64 is used for instruction selection.

I can not find a way to exactly count how cache miss affects.

Shall we implement MOVW $imme-16bit, Rn for ARMv7 first? At least it is sure to be optimized.

I have implemented movw/movt pair in patch set 2 of CL 41190, https://go-review.googlesource.com/?polygerrit=0#/c/41190/

Unfortunately the go1 benchmark test shows no improvement. Please check the attachment for details.

.

I will try if only "MOVW $imm-16, Reg" can optimize ARM code later.

There is a slight improvement with only "movw $imm16, Reg" in go1 benchmark test.

CL https://golang.org/cl/41190 mentions this issue.

With patch set 4 of CL 41190, I ran the go1 benchmark test three rounds, each with count=50. I got
old50_1 vs new50_1
[Geo mean] 747µs 744µs -0.34%
[Geo mean] 6.57MB/s 6.59MB/s +0.33%
old50_2 vs new50_2
[Geo mean] 749µs 747µs -0.31%
[Geo mean] 6.56MB/s 6.58MB/s +0.30%
old50_3 vs new50_3
[Geo mean] 747µs 745µs -0.28%
[Geo mean] 6.56MB/s 6.60MB/s +0.47%

All showed improvements with "MOVW $imm16, Reg".

I tried to attach a zip file containing all log files. But always got
"We don’t support that file type. with a PNG, GIF, JPG, DOCX, PPTX, XLSX, TXT, PDF, or ZIP. "

So I have to attach the screenshots. Really sorry for that. And I will update CL 41190's commit message with new test results which look more reasonable.

Please don't post screenshots of text. Just copy/paste the text. But I don't see why this bug needs 3 sets of benchmarks pasted in a row. Shouldn't it just be in the commit message of your CLs?

OK. I will attach the text directly next time. I did more rounds of test, since the results have difference among each round, and more test results can make the improvement more reliable.

current status,

1. "VMOV $immediate, Reg" already exists
2. MOVW/MOVT pair is not efficient as expected
3. MOVW $imm16, Reg is merged

Can we do any more for this issue?

@benshi001 Thank you for making the CL and investigating other possibilities.

Closing for now (fixed in CL https://go-review.googlesource.com/c/41190/). Feel free to reopen if you find there is more to do.