On Tue, Jun 24, 2014 at 10:31 PM, Alp Toker <[email protected]> wrote: > The attached patch removes code that apparently supported '.bc' binary LLVM > bitcode as a frontend input kind. > > There were no tests and it's unclear if it was in a working state.
That's vaguely surprising. > I'm > comfortable removing this because it doesn't really align with the > frontend's primary objective of diagnosing textual input and lowering source > code. It seems about as likely that someone would use this as they would use .ll input files. I'm not sure how likely either is. As a developer I usually use the llc, etc, tools - but sometimes I pass bitcode to clang to link (possibly after using llvm-link to link two bitcode files together & I want a linker invocation that has all the standard libraries, etc rather than trying to invoke the linker myself or do two steps of assemble+link). > The removal lets us parse and diagnose '.ll' IR inputs more efficiently > without duplicating file contents into memory. Curious - how's that the case? > (If there's desire to keep '.bc' support and someone contributes tests for > it, I'm fine to explore other ways to achieve this optimisation.) > > Requires the recently posted MemoryBuffer patch. > > Alp. > > -- > http://www.nuanti.com > the browser experts > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
