[lld] r353200 - Inline a trivial function and update comment. NFC.

[Rui Ueyama via llvm-commits]

Author: ruiu
Date: Tue Feb  5 11:19:45 2019
New Revision: 353200

URL: http://llvm.org/viewvc/llvm-project?rev=353200&view=rev
Log:
Inline a trivial function and update comment. NFC.

Modified:
    lld/trunk/ELF/Arch/X86.cpp

Modified: lld/trunk/ELF/Arch/X86.cpp
URL: http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Arch/X86.cpp?rev=353200&r1=353199&r2=353200&view=diff
==============================================================================
--- lld/trunk/ELF/Arch/X86.cpp (original)
+++ lld/trunk/ELF/Arch/X86.cpp Tue Feb  5 11:19:45 2019
@@ -66,8 +66,6 @@ X86::X86() {
   DefaultImageBase = 0x400000;
 }
 
-static bool hasBaseReg(uint8_t ModRM) { return (ModRM & 0xc7) != 0x5; }
-
 RelExpr X86::getRelExpr(RelType Type, const Symbol &S,
                         const uint8_t *Loc) const {
   switch (Type) {
@@ -107,14 +105,14 @@ RelExpr X86::getRelExpr(RelType Type, co
     // load an GOT address to a register, which is usually %ebx.
     //
     // So, there are two ways to refer to symbol foo's GOT entry: foo at GOT or
-    // foo at GOT(%reg).
+    // foo at GOT(%ebx).
     //
     // foo at GOT is not usable in PIC. If we are creating a PIC output and if we
     // find such relocation, we should report an error. foo at GOT is resolved to
     // an *absolute* address of foo's GOT entry, because both GOT address and
     // foo's offset are known. In other words, it's G + A.
     //
-    // foo at GOT(%reg) needs to be resolved to a *relative* offset from a GOT to
+    // foo at GOT(%ebx) needs to be resolved to a *relative* offset from a GOT to
     // foo's GOT entry in the table, because GOT address is not known but foo's
     // offset in the table is known. It's G + A - GOT.
     //
@@ -122,12 +120,12 @@ RelExpr X86::getRelExpr(RelType Type, co
     // different use cases. In order to distinguish them, we have to read a
     // machine instruction.
     //
-    // The following code implements it. We assume that Loc[0] is the first
-    // byte of a displacement or an immediate field of a valid machine
+    // The following code implements it. We assume that Loc[0] is the first byte
+    // of a displacement or an immediate field of a valid machine
     // instruction. That means a ModRM byte is at Loc[-1]. By taking a look at
-    // the byte, we can determine whether the instruction is register-relative
-    // (i.e. it was generated for foo at GOT(%reg)) or absolute (i.e. foo at GOT).
-    return hasBaseReg(Loc[-1]) ? R_GOT_FROM_END : R_GOT;
+    // the byte, we can determine whether the instruction uses the operand as an
+    // absolute address (R_GOT) or a register-relative address (R_GOT_FROM_END).
+    return (Loc[-1] & 0xc7) == 0x5 ? R_GOT : R_GOT_FROM_END;
   case R_386_TLS_GOTIE:
     return R_GOT_FROM_END;
   case R_386_GOTOFF: