[PATCH] Optimize long branch for MIPS64 by removing calculation of %higher and %highest

Mark Seaborn mseaborn at chromium.org
Wed May 14 17:07:50 PDT 2014


LGTM for the code change, with the caveat about tail calls below and the warning that I'm not an expert on MIPS. :-)

================
Comment at: lib/Target/Mips/MipsLongBranch.cpp:345
@@ +344,3 @@
+      //
+      //   lui $at, %highest($tgt - $baltgt)
+      //   daddiu $at, $at, %higher($tgt - $baltgt)
----------------
Including this snippet seems a bit too verbose to me.  You don't need to document what the code used to do -- we have version control for that. :-)

Just say you assume the jump is within-function, so the offset is within +/- 2GB.

================
Comment at: lib/Target/Mips/MipsLongBranch.cpp:352
@@ +351,3 @@
+      // values only when the offset is greater than 4GB, which is highly
+      // unlikely, if not impossible when compiling a single function.
+      //
----------------
I don't think you answered dsanders' question about why it's valid to assume that the jump is within-function.

I was wondering whether tail calls to other functions would become jumps that would need handling via MipsLongBranch.  The answer seems to be that LLVM always compiles function calls to indirect jumps on MIPS.  (However, GCC does compile tail calls to direct jumps.)  That answer seems a bit crazy, so I'm not sure if it's right.  You should check.  Does the MIPS linker insert veneers to handle long direct jumps the same way ARM linkers do?

http://reviews.llvm.org/D3281






More information about the llvm-commits mailing list