f18 icon indicating copy to clipboard operation
f18 copied to clipboard

[LLVMify F18] Replace uses of standard streams library with LLVM streams

Open DavidTruby opened this issue 5 years ago • 9 comments

LLVM has its own stream library for a number of reasons, we should use this as well to sync up with them. See https://llvm.org/docs/CodingStandards.html for the reasons why their stream library is preferred.

DavidTruby avatar Feb 04 '20 14:02 DavidTruby

Please look at semantics/mod-file.cpp to be sure it'll work. That the modfile is written to memory before writing to a file so f18 can avoid re-writing mod files that do not change. I don't anticipate a problem.

sscalpone avatar Feb 04 '20 14:02 sscalpone

Assuming I understand correctly that you mean the places where it outputs to a std::stringstream before writing that to a file, llvm has a raw_string_ostream class that is pretty much a drop in replacement for std::stringstream, so I can't see there being an issue.

DavidTruby avatar Feb 04 '20 15:02 DavidTruby

Why replace the use of the standard library stringstream for the construction of the module file content? Is the nonstandard facility significantly faster?

klausler avatar Feb 04 '20 17:02 klausler

The non-standard facility is faster because it makes more assumptions about what the type of the buffer is. Additionally it's not templated so it can be forward declared safely. The code guidelines for llvm go over why they prefer the use of their streams library over standard streams. The standard streams library is also littered with global objects with non-trivial constructors that are pretty unsavoury.

DavidTruby avatar Feb 04 '20 18:02 DavidTruby

How much faster does f18 run on a large compilation when using the nonstandard stringstream?

klausler avatar Feb 04 '20 18:02 klausler

I haven't had the time to port it yet. However I think it's a somewhat academic discussion as LLVM forbids the use of the standard streams library for a number of reasons, as listed in the LLVM code guidelines.

DavidTruby avatar Feb 04 '20 18:02 DavidTruby

LLVM has historically avoided iostream objects because iostream requires run-time construction of static objects, which is a general prohibition for libraries. But sstream is specifically characterized as "not problematic".

klausler avatar Feb 04 '20 18:02 klausler

Sure, stringstream is not problematic in the same way. However, most llvm libraries only provide conversions to raw_ostream& etc, and raw_ostream is preferred over standard streams regardless for other reasons.

DavidTruby avatar Feb 04 '20 19:02 DavidTruby

Progressing under #1047

RichBarton-Arm avatar Mar 05 '20 11:03 RichBarton-Arm