search

GaloisInc / llvm-pretty

An llvm pretty printer inspired by the haskell llvm binding
Other
28 stars 15 forks source link

Split Text.LLVM.AST into Data.LLVM.IR and Data.LLVM.IR.Textual? #6

Open angerman opened 8 years ago

angerman commented 8 years ago

The AST is used in the llvm-pretty-bc-parser as well, and could be useful on it's own, would it hurt to split Text.LLVM.AST into the IR data representations (Data.LLVM.IR) and the textual pretty printer (Data.LLVM.IR.Textual)?

That would allow to just import the IR.

elliottt commented 8 years ago

I think that this would help to deal with the problems outlined in #5, as it would seem a bit more natural to import a module called Text.LLVM.AST.Pretty37, when you wanted to pretty-print for that version of LLVM. Any preference on where the new modules go?

angerman commented 8 years ago

I'd vote for Data.LLMV.IR for the AST, as it's effectively the IR LLVM Data representation, unless I'm somehow mistaken.

I'm not so sure about the Textural PrettyPrinter. I'm currently trying (which is also why I came across this, to write a bit code emitter for the IR). The bitcode parser, currently is in Data.LLVM.BitCode. (llvm-pretty-bc-parser package).

So I'd suggest to keep the Data.LLVM prefix for consistency, but am not certain about the proper naming for the Textual IR Printer.

langston-barrett commented 2 years ago

I would go even further: I think it's worth splitting llvm-pretty into two separate Cabal packages/libraries, one for the AST and one for the printer. As @angerman highlights, there are plenty of use-cases that might involve the AST without involving pretty-printing, those use-cases shouldn't need to bring in pretty-printing dependencies such as monadLib. This is fairly easy to do these days with a cabal.project file, and we may be able to retain full backwards-compatibility just by re-exporting stuff from Text.LLVM.AST.