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

Ramkumar Ramachandra artagnon at gmail.com
Mon Jan 12 13:32:14 PST 2015


================
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) {
----------------
reames wrote:
> 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.  
> 
> 
x86mmx is an x86-specific type that's actually a 64-bit vector. There are already tests specifically for mmx in the same directory; I just want to document common name manglings in one place.

Yeah, I'll look into gc.relocate and vectors after this.

================
Comment at: test/CodeGen/Generic/overloaded-intrinsic-name.ll:1
@@ +1,2 @@
+; RUN: llc < %s
+; Tests the name mangling performed by the codepath following
----------------
reames wrote:
> 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.  
`opt -verify -S` it is then. Why not codegen? I can see plenty of similar code in the same directory.

I'll add to `statepoint-call-lowering` in subsequent patches.

================
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)
----------------
reames wrote:
> Given that these don't have check statements, how do you judge correctness of the tests?
We just want to ensure that it runs fine. Specifically checking name mangling against the types of arguments is not something I'm aiming for in this patch.

http://reviews.llvm.org/D6915

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






More information about the llvm-commits mailing list