[GHC] #13427: Per-function code-generation options
GHC
ghc-devs at haskell.org
Tue Mar 14 20:19:53 UTC 2017
#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
More information about the ghc-tickets
mailing list