[llvm-dev] How to tell LLVM to treat Commutable library calls as such, for example multiplication?

Joan Lluch via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 12 11:40:26 PDT 2019

Hi Finkel and Tim

Thanks for your responses. 

About this topic, and partly as a matter of experimentation, I have implemented a function that gets called for ‘commutable’ libcalls just at the beginning of my LowerCall implementation. I conveniently called it ‘AnalizeCommutableLibCall’. This function performs a recursive search up the operand tree starting from the libcall operands until it finds a ‘CopyFromReg’ or another LibCall operation action. The function determines the register number encountered at the end of the search, either physical or virtual, for each of the two commutable operands. In case the first operand got a bigger register number than the second operand, then the operands are swapped. This apparently simple thing seems to work in all cases because, ultimately, physical register assignations go in ascending number for formal arguments and function returns. By placing the (commutable) operands in ascending register numbers, even if these register numbers were found way up on the operand tree, the compiler never needs to perform any explicit or implicit register swaps, so this often results in less register overhead and shorter code. Much like if the compiler already knew that the call operands were ‘commutable’.

For larger codebases, certainly the compiler has some extra opportunities to swap registers through intermediate instruction results, but the problem remains that registers or intermediate results must still be swapped at some time if Clang dictated so. This circumstance repeats again at every new libcall instruction, regardless of the length of the function, so even if some calls may not get affected, most apparently are.

For now I’m leaving this (initially experimental) function on my target implementation, I can post the code in case there’s some interest, as I found that it systematically produces shorter code and it can't produce any side effects (all what it ultimately does is swapping commutative arguments). 


More information about the llvm-dev mailing list