Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): `-fllvm` with LLVM5 and GHC at `8a1de424`, generates some rather interesting IR with -O2: https://ghc.haskell.org/trac/ghc/attachment/ticket/6084/T6084.ll specifically {{{ ... %ln4QS = bitcast void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)* %ln4QT = load i64*, i64** %Sp_Var %ln4QU = load i64, i64* %R1_Var %ln4QV = load i64, i64* %R2_Var %ln4QW = load float, float* %F1_Var %ln4QX = load double, double* %D2_Var tail call ghccc void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double) %ln4QS( i64* %Base_Arg, i64* %ln4QT, i64* %Hp_Arg, i64 %ln4QU, i64 %ln4QV, i64 undef, i64 undef, i64 undef, i64 undef, i64 %SpLim_Arg, float %ln4QW, double %ln4QX ) nounwind ret void } @Main_p_info = alias i8, bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i8*) define ghccc void @Main_p_info$def(i64* noalias nocapture %Base_Arg, i64* noalias nocapture %Sp_Arg, i64* noalias nocapture %Hp_Arg, i64 %R1_Arg, i64 %R2_Arg, i64 %R3_Arg, i64 %R4_Arg, i64 %R5_Arg, i64 %R6_Arg, i64 %SpLim_Arg) align 8 nounwind prefix <{i64, i64, i64, i64, i64, i64}><{i64 add (i64 sub (i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_slow$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 451, i64 add (i64 sub (i64 ptrtoint (%S4QA_srt_struct* @S4QA_srt$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 12884901888, i64 0, i64 4294967310}> { ... }}} we bitcast `@Main_p_info$def` from `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)` to `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)`. (E.g. we add a `float` and a `double`) to the signature. And then we call the newly bitcasted function with an additional float and double. However `Main_p_info$def` doesn't take those two last arguments, and never does anything with them. At the point where we create `Main_p_info$def` (the `CmmProc`) the `live` value hence does not include registers `F1` and `D1`. Yet at the call site we do expect to pass them. The LLVM backend, simply ignores this, as it always casts functions to the expected type. However a more rigorous backend that tries to unify functions with their callsite signatures falls over at this point. Is it possible that some liveness logic is broken in Cmm here? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6084#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC