The pool remembers what the code forgets
Two distinct globals in one function mean two pool words, laid out in the order the compiler first needed them. Both are fetched up front, then dereferenced, then used.
That ordering carries information the instructions themselves throw away. Here is a pair of functions that add the same two globals in opposite source order:
0 ldr r0, [pc, #8] (->12)
2 ldr r1, [pc, #12] (->16)
4 ldr r0, [r0, #0]
6 ldr r1, [r1, #0]
8 add r0, r1
10 bx lr
12 .word gWarm
16 .word gCool
0 ldr r0, [pc, #8] (->12)
2 ldr r1, [pc, #12] (->16)
4 ldr r0, [r0, #0]
6 ldr r1, [r1, #0]
8 add r0, r1
10 bx lr
12 .word gCool
16 .word gWarm
Every instruction is identical. Every register is identical. The only difference in the whole function is which name sits in which pool slot. On machines with wider instructions the operand order of a commutative add is usually lost for good; here the pool preserves it, so those two rows are load-bearing diff content.
The practical rule: trace which register each pool word ends up in, then read what the arithmetic does to that register. In both listings above r0 gets the first word and r1 the second, and add r0, r1 puts the first-listed global on the left of the +.
Your target treats its two globals differently from each other, so the registers tell you more than the pool order does — but you still need both rows in the right places.
Your task
Write func_083295b0 to reproduce the target assembly.