Re: Status of "Improved LLVM backend"

> > > > I don’t know if generating llvm from stg instead of cmm would be a > > > > better > > > > approach, which is what ghcjs and eta do as far as I know. > > > > > > Wouldn't a step from STG to LLVM be much harder (LLVM IR is a pretty > > > low-level > > > representation compared to STG)?

Re: Status of "Improved LLVM backend"

On Mon, Nov 28, 2016 at 2:43 AM Moritz Angermann wrote: [...] > For the llvm code gen in ghc it’s usually the `_fast` suffix functions. See [1] and > the `genStore_fast` 30 lines further down. My bitcode llvm gen follows that file [1], > almost identically, as can be seen

Re: Status of "Improved LLVM backend"

> On Nov 27, 2016, at 10:17 PM, Michal Terepeta > wrote: > > > Hi, > > > > I’m trying to implement a bitcode producing llvm backend[1], which would > > potentially > > allow to use a range of llvm versions with ghc. However, this is only > > tangentially > >

Re: Status of "Improved LLVM backend"

> Hi, > > I’m trying to implement a bitcode producing llvm backend[1], which would potentially > allow to use a range of llvm versions with ghc. However, this is only tangentially > relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are > other complications

Re: Status of "Improved LLVM backend"

Hi, I’m trying to implement a bitcode producing llvm backend[1], which would potentially allow to use a range of llvm versions with ghc. However, this is only tangentially relevant to the improved llvm backend, as Austin correctly pointed out[2], as there are other complications besides the