For sampleFDO, because the optimized build uses profile generated from previous release, we cannot tell a function without profile is truely cold or just newly created. Currently we treat them conservatively and put them in .text section instead of .text.unlikely. The result is when we persuing the best performance by locking .text.hot and .text in memory, and use huge pages for them, we waste a lot of memory and huge pages for functions actually being cold.
We already have a related option called -profile-sample-accurate. If we uses that option, function without profile will be treated as cold and we won't have the memory/huge pages waste problem, but we are going to see performance problem if new functions actually being hot are treated as cold.
To mitigate the problem, we provide another option called --profile-unknown-in-special-section. For functions without profile, we will still treat them conservatively in compiler optimizations -- for example, treat them as warm instead of cold in inliner. When we use profile info to add section prefix for functions, we will discriminate functions known to be not cold versus functions without profile (being unknown), and we will put functions being unknown in a special text section called .text.unknown. Runtime system will have the flexibility to decide where to put the special section in order to achieve a balance between performance and memory saving.