search for: __literal

...nd.isMergeableConst16()) > return SixteenByteConstantSection; > } > > Can’t we just change the first ‘if’ to: > > if (Kind.isMergeableConst() && !GV.hasName()) { > > That should leave any “named” constants in the __const section instead of moving them to the __literal section. (Though I don’t actually know if anonymous constants were given some name earlier so hasName() is useless at this point). That seems too strict. A private GV can have a name, but it will be printed with a 'L' or 'l' prefix, so it should not be a problem. In other words, i...

>> The literalN sections were developed long ago to support coalescing of >> unnamed constants like 9.897 in source code for architectures that could not >> embed large constants in instructions. The linker could knew how to break >> up the section (e.g. __literal8 is always 8 byte chunks) and coalesce copies >> by content. >> >> ~6 years ago we discovered that gcc would sometimes put user named >> constants into the literal sections (e.g. const double foo 9.897). This was >> an issue because C language rules say &a != &amp...