#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by carter): Ok, I"ll take that as a vote of YES by ghc HQ for this change. I'll contact him + 1-2 other folks i'm attaching a diff / patch file that does this change. also changed my language in the comments to the following {{{ def CC_X86_64_GHC : CallingConv<[ // Promote i8/i16/i32 arguments to i64. CCIfType<[i8, i16, i32], CCPromoteToType<i64>>, // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim CCIfType<[i64], CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>, // Pass in STG registers for floats, doubles and 128bit simd vectors CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCIfSubtarget<"hasSSE1()", CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>, // Pass in STG registers for 256bit simd vectors CCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], CCIfSubtarget<"hasAVX()", CCAssignToReg<[YMM0, YMM1, YMM2, YMM3, YMM4, YMM5, YMM6]>>> ]>; }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8033#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by dterei): Sounds fine. I'd simply email the LLVM mailing list or open a ticket to get the patch merged. Feel free to name drop me if it helps but I don't expect any issues. If that doesn't work I can email one or two people directly which in the past has been faster. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8033#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by carter): @gmainland I don't understand your remark about the registers comment... XMM_n is the lower half of the corresponding YMM_n, the additional rule only fires for "256 bit" vectors, otherwise the lower half is used instead. Could you show me which comment you want to change and how? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8033#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Comment(by carter): relatedly, i'm looking at the llvm calling convention spec, and I'm noticing / just now realizing that 32bit x86 mode doesn't preclude using simd! https://github.com/llvm- mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td#L428 (the ghc calling convention and the associated others) So we perhaps could replicate the simd stanzas and add them to 32bit calling convention on the llvm side? I believe that would have zero impact on any ghc that uses llvm 32bit with the current calling convention because ghc manages its own stack spilling, and would harmonize simd to be llvm + x86 backend specific but not 64bit only (merely leaves the question of the segmenting of various levels of SIMD support that the target has, which is needed for using avx / avx2 correctly anyways, so *shouldnt* change any complexity on our side ). Im not going to add that for now, but just throwing the idea out there, because as is, for supporting interesting SIMD, we need to have a finer grained notion of target going forward *anyways* beyond "is it x86_64" or not *Anyways*, and in some sense, those other notions are *orthogonal* to 32 bit vs 64bit If you two favor such a change, i'll add that to the proposed patch. (we'll stil have to hash out better sub target info in ghc land, but thats separate from making sure the backend has the machinery to support it already or not ) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8033#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler