Thanks for working on this @hectorchu

A few comments:

• it applies to ALL binary ops, not just Add. This seems too big of a change.
• no tests
• what if both operands are pointers?
• since this appears to be specific to xtensa, not sure we want to change this for all architectures.

What do you think?

• happy to make it only for Add
• tests - I'm not the best at testing (especially this) but I'll give it a shot
• if both operands are pointers - The existing code does not check for this condition either. The existing code fails if both are pointers. Anyway this has to be a very very unlikely case.
• happy to make it specific for xtensa as a sort of workaround for their codegen. But how do I check if its xtensa in this part of the code?

Nevermind about checking for xtensa - figured it out.

Hmm weird. I just removed this "workaround" and the build of my module worked. I don't know why but this workaround doesn't seem to be required anymore. I will close this PR until I notice that I need it again.

Also, I think LLVM does this flip already for canonicalization.
(Canonicalization is the process of putting the IR in a particular form, so that later optimizations only have to pattern match on a certain form).

Also, doing this for sub and many other operations changes the behavior which is a bug.

Very interesting observation I just made. So, #5315, removes the "panic: cannot convert pointer to integer". Specifically, by changing the //export malloc to //export tinygo_malloc in baremetal.go. This makes it even more imperative that #5315 is merged.