Function-level optnone is definitely something I would appreciate as well. Optimized code can often look nothing like the original code... and having the whole binary non-optimized is just too slow.
I'm eagerly awaiting its inclusion. It isn't as simple of a task as it would seem. Unfortunately, you can't simply disable all of the passes in LLVM. Some aren't optimizations at all and are transforms required for subsequent optimization passes. MachineFunction passes are even trickier. Some are strictly necessary for correct codegen.
Anyone else find it strange that these slides are filled with some pretty hardcore technical jargon, yet on one of the slides they feel the need to clarify "GDDR5 is very high end graphics memory only found on PC graphics cards"? :)
It was given at some LLVM conference so most people in the audience are probably compiler people who will probably know a lot about compilers and less about GPUs.
Often if you are representing a large company or product you have to go through some brand approval process with your presentation, so spec summaries frequently get the standard marketing descriptions added. It seems stupid in context, but the concern is often the slide being shown out of context.
Wonder how big of a factor that the upstream PS4 OS codebase now using LLVM/Clang was in this decision. Even if the PS4 wasn't FreeBSD based I can see the switch making sense on it's own tbh.
Isn't gold specifically targetted at x86 and/or linux only (I can't remember which)? Having it as part of the LLVM project means they can use a lot of the infrastructure that already exists, and exists to used as libraries, and also allows them to write the code as another set of libraries for use in other unforseen systems. It's also aimed at being a generic linker for use on many different platforms. I don't think gold has these goals; from I remember they were just after speed on their target platform.
The executable binary generally dwarfs the assets (textures, models, level data, audio, etc.) so I doubt it makes sense to defer downloading code. If anything, you'd put any level-specific native code (rare these days - it's mainly scripts) into dynamically loaded libraries.
The executable has to be read from the disk, and until it's fully loaded nothing would show. Since startup time must be minimized it's good to keep your executable size small. Also newer versions would be smaller for updates off the internet. Most of all the executable has to be linked over and over again (by developers) and then copied or written to the some kind of disk/drive somewhere to start it.
But as you've said, maybe moving some big clunky parts to dll would help.
The PS3 uses both SNC and GCC (4.1). The developer has a choice of using SNC or GCC when generating code for the PPU -- the general purpose processor on the PS3 -- but only GCC is available when building code for the SPUs.
SNC is (was?) a great compiler. The code it generated was faster and significantly smaller than that generated by GCC, while being much faster at building to boot. Later versions of SNC added limited C++11 support as well.
