[PATCH] D17863: Swift Calling Convention: add swiftcc

John McCall via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 4 13:26:32 PDT 2016


rjmccall added inline comments.

================
Comment at: lib/Target/X86/X86CallingConv.td:196-199
@@ +195,6 @@
+def RetCC_X86_64_Swift : CallingConv<[
+  // For integers, ECX, R8D can be used as extra return registers.
+  CCIfType<[i8] , CCAssignToReg<[AL, DL, CL, R8B]>>,
+  CCIfType<[i16], CCAssignToReg<[AX, DX, CX, R8W]>>,
+  CCIfType<[i32], CCAssignToReg<[EAX, EDX, ECX, R8D]>>,
+  CCIfType<[i64], CCAssignToReg<[RAX, RDX, RCX, R8]>>,
----------------
t.p.northover wrote:
> manmanren wrote:
> > t.p.northover wrote:
> > > manmanren wrote:
> > > > Hi Tim,
> > > > 
> > > > i1 type is promoted to i8 before reaching here. That is why we don't need to handle i1 here.
> > > > This is what other RetCCs do, such as RetCC_X86_32_Fast, but I am not against making it explicit here.
> > > Where does it get promoted? To me it looks like RetCC_X86_64 directly calls RetCC_X86_64_Swift, which doesn't handle it. It then gets forwarded to RetCC_X86Common which promotes to i8 and only uses AL, DL, CL.
> > > 
> > > I suspect you'll find that something like
> > > 
> > >     define [4 x i1] @foo() {
> > >         %res = insertvalue [4 x i1] undef, i1 true, 3
> > >         ret [4 x i1] %res
> > >     }
> > > 
> > > does not do what you're expecting.
> > Sorry that it took so long for me to get back on this!
> > 
> > It was promoted in TargetLoweringBase::computeRegisterProperties
> >   // Inspect all of the ValueType's smaller than the largest integer
> >   // register to see which ones need promotion.
> > 
> > TLI.getRegisterType(...) for i1 will return i8.
> > 
> Ah, I see. The i1 case is only needed for AVX-512 by the looks of it. Do you know if Swift has a position on that? I would expect the Linux crowd to want to try it out when the chips come along properly, even if Macs don't have them yet.
Steve Canon and I agreed that the swift CC should be stable independent of AVX settings, so you shouldn't ever see vectors larger than 16 bytes in backend lowering.


http://reviews.llvm.org/D17863





More information about the llvm-commits mailing list