Some optimization can also be done for ARM:

1. BICconst <-> ANDconst, SUBconst <-> ADDconst for smaller constant

2. MULA/MULS
   2.1 (ADD a h:(MUL x y)) -> (MULA a x y) needs h.Uses==1
   2.2 (CMPconst [0] (MULA a x y)) -> (CMN a (MUL x y))

3. optimize comparasion
   3.1 (CMPconst [0] L:(ADD x y)) && L.Uses==1 -> (CMN x y)
   3.2 (CMPconst [0] L:(ADD x y)) && L.Uses>1 -> (ADDS x y)

4. combination of MOVB to MOV[HW] & MOVH to MOVW

5. use BFI / BFC to simplify bit operations

6. optimization with MOVBUloadshiftLL, MOVBUloadshiftRA, MOVBUloadshiftRL

7. MULAF/MULAD/MULSF/MULSD
   (ADDF a (MULF x y)) && a.Uses == 1 && objabi.GOARM >= 6 -> (MULAF a x y)
   also needs z:(MULF x y), z.Uses == 1

8. use MOVT/MOVW pair instead of constant pool on ARMv7 (for large constant and symbolic address)

The reason why the following two MOVBs are not combined to a single MOVH, is that the first load (v23) is used twice.

func ssg(s []byte, idx int) {
	s[(idx<<1)+0], s[(idx<<1)+1] = 0, 0
}

This optimization seems can not be done by SSA rules only.

  pass lower begin
  pass lower end [16576 ns]
ssg func([]byte, int)
  b1:
    v1 = InitMem <mem>
    v7 = Arg <int> {idx}
    v8 = MOVDconst <uint> [1] DEAD
    v13 = MOVDconst <int> [1] DEAD
    v15 = MOVDconst <byte> [0] DEAD
    v30 = Arg <*byte> {s} (s[*byte])
    v25 = Arg <int> {s} [8] (s+8[int])
    v28 = SLLconst <int> [1] v7
    v26 = MOVDconst <int> [0] DEAD
    v3 = FlagLT_ULT <flags> DEAD
    v6 = CMPshiftLL <flags> [1] v25 v7
    v14 = ADDconst <int> [1] v28
    v17 = GreaterThanU <bool> v6 DEAD
    v24 = InvertFlags <flags> v6 DEAD
    UGT v6 -> b2 b3 (likely)
  b2: <- b1
    v21 = ADDshiftLL <*byte> [1] v30 v7 DEAD
    v23 = MOVBstorezeroidx <mem> v30 v28 v1
    v12 = CMP <flags> v14 v25
    v27 = LessThanU <bool> v12 DEAD
    ULT v12 -> b4 b3 (likely)
  b3: <- b1 b2
    v18 = Phi <mem> v1 v23
    v19 = CALLstatic <mem> {runtime.panicindex} v18
    Exit v19
  b4: <- b2
    v29 = ADD <*byte> v30 v14 DEAD
    v31 = MOVBstorezeroidx <mem> v30 v14 v23
    Ret v31

This is because the bounds check might panic after assigning the s[(idx<<1)+0] but before assigning s[(idx<<1)+1]. If you ensure the bounds check, if it fails, fails before the assignment, then it should work.

func ssg(s []byte, idx int) {
	_ = s[(idx<<1)+1]
	s[(idx<<1)+0], s[(idx<<1)+1] = 0, 0
}

Thank you. Keith.

But such kinds of code looks odd. Is it possible to clobber the MOVBstore if it was only referred by a bound check? Or making bound check omits disappeared store/load ?

Combining the stores is not legal in the original example. If the first array index succeeds but the second fails, the language semantics require that the first write happens and the second doesn't. That means that the first write must be just a single byte; it can't be combined with the second write. The "in-between" memory state is observable if someone recovers the panic.

That requirement is realized in SSA by passing the results of the first store to the bounds check.

Thank you. Keith. I see the key point.

386/amd64:

1. "MOVFconst $0.0, F0" -> "LDZ F0", "MOVFconst $1.0, F0" -> "LD1 F0"

2. implement DIVSSload/DIVSDload/MULLload

3. support more instructions use a destination memory operand, such as (ADD/SUB/OR/EOR/AND)Lconstmodify, (ADD/SUB/OR/EOR/AND)Lmodify

4. support more instructions use a source memory operand, such as CMP

5. optimize 386 with BT/BTC/BTR/BTS

6. improve memory operands with register indexed form

7. can more combined load/store be optimized?

8. can optimization be done with CMOV/FMOVcc?

9. can some optimization be done with FIADD/FISUB/FIMUL/FIDIV ?

about 40% of them have been implemented via my recent commits, others do not improvement.