[PATCH] getMangledTypeStr: clarify how it mangles types, and add tests

Philip Reames listmail at philipreames.com
Mon Jan 12 10:22:30 PST 2015


Comments inline.  I like the general direction of the revised patch.


================
Comment at: lib/IR/Function.cpp:450
@@ -449,9 +449,3 @@
 /// mangling scheme used by 'any' types in intrinsic signatures.  The mangling
-/// of named types is simply their name.  Manglings for unnamed types consist
-/// of a prefix ('p' for pointers, 'a' for arrays, 'f_' for functions)
-/// combined with the mangling of their component types.  A vararg function
-/// type will have a suffix of 'vararg'.  Since function types can contain
-/// other function types, we close a function type mangling with suffix 'f'
-/// which can't be confused with it's prefix.  This ensures we don't have
-/// collisions between two unrelated function types. Otherwise, you might
-/// parse ffXX as f(fXX) or f(fX)X.  (X is a placeholder for any other type.)
+/// of named types is simply their name.  Manglings for unnamed types consist of
+/// a prefix ('p' for pointers, 'a' for arrays, 'f_' for functions) combined
----------------
Please separate line breaking differences into their own patch.  It's hard to tell what actually changed in this comment.

================
Comment at: lib/IR/Function.cpp:459
@@ -458,1 +458,3 @@
+/// floats, and vectors ('i', 'f', and 'v' prefix in most cases) fall back to
+/// the MVT codepath, where they could be mangled to 'x86mmx', for example.
 static std::string getMangledTypeStr(Type* Ty) {
----------------
x88mmx isn't what actually appears in your test?  Why the difference?  (Clarify in comment please.)


FYI - I expect you'll run into some problems actually lowering vectors gc.relocates.  It's not a case we've explored.  



================
Comment at: test/CodeGen/Generic/overloaded-intrinsic-name.ll:1
@@ +1,2 @@
+; RUN: llc < %s
+; Tests the name mangling performed by the codepath following
----------------
This is probably better as an opt -verify test.  Not sure CodeGen is the right place for it either.

Alternatively, you could go the other direction and adapt this to be a gc lowering specific test.  This would involve checking the assembly output, but might be reasonable tor exercising the vector path it seems like you're interested in.  

================
Comment at: test/CodeGen/Generic/overloaded-intrinsic-name.ll:4
@@ +3,3 @@
+; getMangledTypeStr(). Exercise the most general case,
+; llvm_anyptr_type, using gc.relocate and gc.statepoint.
+
----------------
You might want to clarify that the use of gc.* is arbitrary and that these are no GC tests.  It's mostly clear, but could be a bit more explicit.  

================
Comment at: test/CodeGen/Generic/overloaded-intrinsic-name.ll:7
@@ +6,3 @@
+; function and integer
+define i32* @test_iAny(i32* %v) {
+       %tok = call i32 (i1 ()*, i32, i32, ...)* @llvm.experimental.gc.statepoint.p0f_i1f(i1 ()* @return_i1, i32 0, i32 0, i32 0, i32* %v)
----------------
Given that these don't have check statements, how do you judge correctness of the tests?

http://reviews.llvm.org/D6915

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list