[GHC] #13427: Per-function code-generation options
#13427: Per-function code-generation options -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On ghc-devs Ed Kmett has [[https://mail.haskell.org/pipermail/ghc- devs/2017-March/013923.html|asked]] for some way to more precisely specify code generation options (e.g. should AVX be used?). This idea has taken a few different shapes in the thread, but I suspect that the most sensible approach is add something like a `TARGET` pragma, which the user could attach to a top-level binding. Since the interactions with inlining are non-trivial, I suspect you would want to require that this only be applied to `NOINLINE` bindings. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13427 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13427: Per-function code-generation options -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Annoyingly, they probably _do_ need to be able to INLINE in order to be at all useful. Consider a situation where a user builds a module that all requires an "avx2" target to build, then carefully wraps any use of that module in a user-space ISA check. We really _want_ these things to inline out int the surrounding caller. With the goal being to have all of that heavy haskell code erase, and just individual assembly instructions remain. Ultimately, how far it'll inline becomes a function of the fact that e.g. With a TARGET pragma saying we'll use avx2, the fact that without avx2, __m256's being passed in ymm registers (which don't exist yet) isn't a thought we can think at all. Basically, the only source of data that needs avx2 and the registers it entails is something that had the flag on in the first place, and given these all wind up being opaque looking primops its not like we have rewrite rules that are going to commute these out of the ISA check. If we start changing our story about how we do all the vector primitives to support downgrading to an emulation layer, that all might change. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13427#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC