Rename compiler-generated constants non-sequentially

In the course of our runtime optimization of shader networks, we
generate lots of new constant symbols (for example, as we optimize an
"a = b + c" into "a = newconst" if b and c can be determined to be
constants). The new constants are named with a numerical suffix doled
out in a sequental manner.

I've always thought that maybe it would be helpful for me when
debugging optimizer output if the name of the symbol also revealed the
value of the constant it held (when possible). Never did anything
about it.

Now it turns out that this has an application for JIT to PTX, where
the PTX cache can save compilation-to-PTX time if it encounters LLVM
IR that is exactly the same as it has seen before and is cache.  If
the constants are generated in a different order, it generates
non-functional, purely text differences in the code we generate, and
this means the PTX cache doesn't function as efficiently as possible.

So this change alters the compiler-generated constant naming for two
cases: int constants, and string constants. The int constants append
the value of the integer (using '_' instead of '-' for negatives), and
the string constants append the hexidecimal value of the ustring hash
for that string. In both cases it does this without using or
incrementing the `m_next_newconst` counter that it uses to
sequentially name the other types that can't easily encode the value
to generate a unique name.

It's really to help the PTX cache, but as a side benefit, it will
be slightly easier for me to make sense of the optimized code when
I need to read it with my own eyes while debugging.

Signed-off-by: Larry Gritz <lg@larrygritz.com>

src/liboslexec/runtimeoptimize.cpp

@@ -237,8 +237,32 @@ RuntimeOptimizer::add_constant(const TypeSpec& type, const void* data,
         if (type.is_unsized_array())
             newtype.make_array(datatype.numelements());
 
-        Symbol newconst(ustring::fmtformat("$newconst{}", m_next_newconst++),
-                        newtype, SymTypeConst);
+        ustring symname;
+        if (newtype.is_int()) {
+            // If it's a constant integer, make the name $newconst_int42 and
+            // if it's negative, $newconst_int_42 (because we can't put a
+            // minus sign in a symbol name). This is easier to read than
+            // naming them sequentially (you know the value in the constant)
+            // and it means the name will be the same regardless of the order
+            // in which we made the constants (helpful for PTX cache
+            // behavior).
+            int val = *(const int*)data;
+            symname = ustring::fmtformat("$newconst_int{}{}",
+                                         val < 0 ? "_" : "", abs(val));
+        } else if (newtype.is_string()) {
+            // If it's a constant string, make the name $newconst_str_HASH
+            // where HASH is the hex value of the hash of that ustring. This
+            // ensures that the name will be the same regardless of the order
+            // in which we made the constants (helpful for PTX cache
+            // behavior).
+            ustring val(*(const char**)data);
+            symname = ustring::fmtformat("$newconst_str{:08x}", val.hash());
+        } else {
+            // All other cases, just name it sequentially as $newconst_1,
+            // $newconst_2, etc.
+            symname = ustring::fmtformat("$newconst{}", m_next_newconst++);
+        }
+        Symbol newconst(symname, newtype, SymTypeConst);
         void* newdata = nullptr;
         TypeDesc t(newtype.simpletype());
         size_t n = t.aggregate * t.numelements();