search for: __literal8

...tions, etc), > what exactly that is not supported? 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 != &b, but if ‘a’ and ‘b’ are the contain the...

>> 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 != &...

...? >> >> >> 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 != &...

...Section (__TEXT, __const_coal): 128 | Section (__DATA, __mod_init_func): 4 | Section (__DATA, __mod_init_func): 4 Section (__DATA, __bss): 32 | Section (__DATA, __bss): 65 Section (__TEXT, __textcoal_nt): 116324 | Section (__TEXT, __textcoal_nt): 168920 Section (__TEXT, __literal8): 8 | Section (__TEXT, __eh_frame): 88636 Section (__TEXT, __StaticInit): 147 | Section (__TEXT, __StaticInit): 166 Section (__IMPORT, __jump_table): 12790 | Section (__IMPORT, __jump_table): 12410 Section (__IMPORT, __pointers): 136 | Section (__IMPORT, __pointers):...

Is there a way to distinguish between GlobalValues that are user-defined and those that are compiler-defined? I am looking for a function that I can use to tell if a GlobalValue is user-defined , something like "GlobalValue::isUserDefined", which returns true for user-defined GlobalValue. I'm trying to make changes to prevent llvm from placing user-defined constant arrays in the

...seDirectiveSectionSwitch("__TEXT", "__literal4", - MCSectionMachO::S_4BYTE_LITERALS, - 4); - if (IDVal == ".literal8") - return ParseDirectiveSectionSwitch("__TEXT", "__literal8", - MCSectionMachO::S_8BYTE_LITERALS, - 8); - if (IDVal == ".literal16") - return ParseDirectiveSectionSwitch("__TEXT","__literal16", -...