#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