#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: llvm/should_compile/T8131 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): Can also trigger this from Haskell. {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.Prim import GHC.IO main = IO $ \s -> let (# s1, p0 #) = newByteArray# 10# s (# s2, p #) = unsafeFreezeByteArray# p0 s1 (# s3, q #) = newByteArray# 10# s2 in (# copyByteArray# p 0# q 0# 10# s, () #) }}} {{{ rwbarton@adjunction:/tmp$ ~/ghc-head/bin/ghc m -fllvm -fforce-recomp [1 of 1] Compiling Main ( m.hs, m.o ) WARNING: Non constant alignment value given for memcpy! Please report to GHC developers Linking m ... }}} The `llvm.memcpy` intrinsic requires that its `align` argument be a literal. With `-fllvm` but not `-O`, somewhere along the way the alignment argument to the `MO_Memcpy` gets stored in a Cmm register and the register gets used for the `llvm.memcpy` call, which isn't good enough. With (`-fllvm` and) `-O`, the store to a register gets eliminated and the `llvm.memcpy` call does use a literal alignment argument. That's why T7571 and the Haskell program above work with `-O` but not without. (It doesn't have anything to do with the `if (1)` in T7571.) Fragile. Your T8131 is expected to not compile, I think, because there the alignment argument really is nonconstant. Given that the alignment for `MO_Memcpy` is only used in the LLVM backend, and there it is required to be constant, I would be inclined to move it from a MachOp argument to a parameter of the MachOp constructor, like {{{ data CallishMachOp = ... | MO_Memcpy Alignment -- or would another type be more appropriate? }}} I have a half-finished patch that implements this. Besides eliminating the requirement of ensuring the alignment argument is a literal, it also removes some special cases in the other backends that have to throw away the alignment argument before generating a `memcpy` function call. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: llvm/should_compile/T8131 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by rwbarton): This patch is basically done. I preserved the four-argument syntax for `prim %memcpy` etc. in `.cmm` files. This was trickier than I expected due to the tying-the-knot technique used to resolve Cmm names during parsing: we can't pattern-match on the alignment `CmmExpr` argument (to check whether it is a `CmmLit`) while producing the `MO_MemCpy` call. My workaround was to fail in a "pure" way, with `pprPgmError`, producing a rather ugly error message. A better solution here is welcome. But, this only affects compilation of `.cmm` files so it's not so bad if the edges are a bit rough IMO. Here is the patch for review, particularly of that parsing bit but also generally. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: llvm/should_compile/T8131 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ----------------------------------------------+---------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: Priority: high | infoneeded Component: Compiler | Milestone: Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llvm/should_compile/T8131 | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by thoughtpolice): * status: patch => infoneeded -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D624 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"681973c31c614185229bdae4f6b7ab4f6e64753d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="681973c31c614185229bdae4f6b7ab4f6e64753d" Encode alignment in MO_Memcpy and friends Summary: Alignment needs to be a compile-time constant. Previously the code generators had to jump through hoops to ensure this was the case as the alignment was passed as a CmmExpr in the arguments list. Now we take care of this up front. This fixes #8131. Authored-by: Reid Barton Dusted-off-by: Ben Gamari Tests for T8131 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: bgamari, carter, thomie Differential Revision: https://phabricator.haskell.org/D624 GHC Trac Issues: #8131 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: thomie, this looks like a much different failure mode than what this bug described (which was due to our inability to guarantee that alignments that were passed to LLVM were constant). Could you open a new bug describing this new failure? I'm going to close this. Feel free to add a reference to the new bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8131#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler