GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — GitHub - angerman/data-bitcode-llvm: Data.BitCode.LLVM

BranchesTags
Open more actions menu

Latest commit

 

History

48 Commits
48 Commits

Folders and files

NameName
Last commit message
Last commit date
src/Data/BitCode
src/Data/BitCode
 
 
test
test
 
 
.gitignore
.gitignore
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 
Setup.hs
Setup.hs
 
 
cabal.project
cabal.project
 
 
data-bitcode-llvm.cabal
data-bitcode-llvm.cabal
 
 
default.nix
default.nix
 
 
package.yaml
package.yaml
 
 
stack.yaml
stack.yaml
 
 

Repository files navigation

Data.BitCode.LLVM

A module to produce bitcode from llvm module descriptions.

TODO

High prio

  • Extend the call instruction to carry the symbol, signature and calling conv, the call is performed with, and verify that the symbols type matches the signature; and calling conv if symbol is a Function Symbol. If Symbol is a reference ensure that the signature matches. (Data.BitCode.LLVM should automatically insert the required ptr cast if the symbol does not match). Also error if neither a Reference with matching signature nor a Function. I don't think calling anything else makes any sense?
  • Drop the stupid Type first item from the instruction records. This should be computed using instTy.
  • Make instTy work for getElementPointer.
  • Write tests to verify that instTy works as expected.
  • Verify, e.g. in mkInstRec for Call (e.g. everywhere where we do not use instTy that the type we encode matches the one we should expect.
  • Fix getValue. We currently assume that we have no fwd references. And hence can always load the value, but llvm does not work that way for fwd references. There the value and type are encoded after each other (ValueId, TypeId). If it's non fwd reference, it's just ValueId. (see getValueTypePair in BitCodeReader). Similarly this is required to support fwd references in ToBitCode.
  • Collapse constants.

General

  • Stop handrolling your monads. (Use transformers, and derive!)
  • Better error reporting (e.g. see preliminaries in Data.BitCode.LLVM.Util) Maybe using ExceptT to give good hints as to what faild?
  • More type verification. (E.g. let's try to make sure you just can not construct invalid code)

About

Data.BitCode.LLVM

Topics

bitcodehaskellllvm

Resources

Readme
BSD-3-Clause license
Activity

Stars

9 stars

Watchers

3 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.