#9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you be more specific? Why are these "optimisations" wrong for GHCJS? Could they be wrong for other architectures? Concretely, what change do you propose? Built-in rules (like those in `PrelRules` have access to `DynFlags`. If necessary you could make the rule conditional on the `GHCJS` flag (whatever that is). Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9736#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): I've made the `removeOp32` operation target word size dependent (from `DynFlags`) and `rightShiftLogical` use a correctly sized word for the target. I'm not 100% sure what's the best way to do `removeOp32` for GHCJS, since `ArchJavaScript` has to be treated as 32 bit (that's the only word size available for bitwise operations), but numbers can have a bigger range. In most cases, the primops already handle truncation, and the dataflow analysis in the optimizer removes the superfluous narrowing operations. In some situations, narrowing is still needed, for example when a value is obtained from a foreign operation. Since most `NarrowInt32` operations are actually unnecessary for GHCJS, and I'm not sure how well the optimizer will be able to strip the `NarrowInt32Op` from for example `Int32` operations, I'm not adding an exception for `ArchJavaScript` in `removeOp32` and deal with exceptional situations like foreign return values individually in the desugarer. If it turns out that there are situations that can't be handled this way, I'll send another change request for that, like below: {{{#!hs removeOp32 :: RuleM CoreExpr removeOp32 = do dflags <- getDynFlags if wordSizeInBits dflags == 32 && -- JavaScript has 32 bit bitwise operations -- but numbers have a greater range platformArch (targetPlatform dflags) /= ArchJavaScript then do [e] <- getArgs return e else mzero }}} (and unfortunately I'd have to copy/paste the whole PrelRules module into GHCJS again if I'm too late) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9736#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D502 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4dd87c5e3ebd0569fdd19695f3e9c82102404a4f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4dd87c5e3ebd0569fdd19695f3e9c82102404a4f" use correct word size for shiftRightLogical and removeOp32 Summary: shiftRightLogical used a host sized Word for the intermediate value, which would produce the wrong result when cross compiling to a target with a different word size than the host. removeOp32 used the preprocessor to bake in word size assumptions, rather than getting the target word size from DynFlags Test Plan: validate Reviewers: hvr, rwbarton, carter, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D502 GHC Trac Issues: #9736 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9736#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler