Consider reloc info mode when merging constant pool entries

src/assembler.cc

Index: src/assembler.cc
diff --git a/src/assembler.cc b/src/assembler.cc
index 553e37da40e125c0c22f4d7de5eac3aacf44e5d4..9214023ca0d6de9da9bffb0002471bf6a522d899 100644
--- a/src/assembler.cc
+++ b/src/assembler.cc
@@ -819,6 +819,8 @@ const char* RelocInfo::RelocModeName(RelocInfo::Mode rmode) {
       return "no reloc 32";
     case NONE64:
       return "no reloc 64";
+    case NONEINTPTR:
+      return "no reloc intptr";
     case EMBEDDED_OBJECT:
       return "embedded object";
     case DEBUGGER_STATEMENT:
@@ -966,6 +968,7 @@ void RelocInfo::Verify(Isolate* isolate) {
     case WASM_MEMORY_SIZE_REFERENCE:
     case NONE32:
     case NONE64:
+    case NONEINTPTR:
       break;
     case NUMBER_OF_MODES:
     case PC_JUMP:
@@ -1931,7 +1934,7 @@ ConstantPoolEntry::Access ConstantPoolBuilder::AddEntry(
     std::vector<ConstantPoolEntry>::iterator it = info.shared_entries.begin();
     int end = static_cast<int>(info.shared_entries.size());
     for (int i = 0; i < end; i++, it++) {
-      if ((entry_size == kPointerSize) ? entry.value() == it->value()
+      if ((entry_size == kPointerSize) ? entry.IntValueMayBeMergedWith(*it)

[bradnelson, 2016/06/08 00:58:32]

It seems strange to use carnal knowledge of entry to decide which method to
call? Also, just because entry_size != kPointerSize, doesn't seem that means you
can merge mismatched relocation types. Or am I missing something?

[Mircea Trofin, 2016/06/08 03:32:16]

This is inherited (previous) code, and I agree, overall the logic here isn't
ideal. My goal was to initially just nudge the constant pool logic to support
categories of constants, and then try to clean this up, but it may be a small
enough additional change to do it now. Let me give it a go.

                                        : entry.value64() == it->value64()) {
         // Merge with found entry.
         entry.set_merged_index(i);