Re: [edk2] [PATCH 0/2] AARCH64 tiny code model support
On 10 August 2015 at 12:27, Ard Biesheuvel ard.biesheu...@linaro.org wrote: The AARCH64 GCC builds use the GCC large code model by default, simply because it is the code model that requires the least amount of hacking to produce code that supports the PE/COFF conversion applied by Tianocore. However, it is suboptimal in more than one way: - each symbol reference requires a PC-relative literal load (to obtain the address of the memory location that stores the address of the symbol) and 8 bytes to store the address itself, so it uses more space than necessary; - loading the symbol address may stall on the D-cache - each symbol address is an absolute address which requires fixing up by the PE/COFF loader - the large model is not recommended by the GCC developers, and not used very widely so it does not receive a lot of testing coverage. Now that we can support relative AARCH64 relocations, we can actually switch to the GCC tiny code model, which does away with the literals, and simply uses PC-relative references to refer to the symbol directly. This does impose a 1 MB size limit on modules, but this limit is exceeded only very rarely, and we can work around it by switching to the small or large model in that case. Patch #1 overrides the BuildOptions for the DEBUG Shell build to use the small model, since its size exceeds the 1 MB limit. Patch #2 sets the AARCH64 code model to 'tiny' by default. For the ArmVirtQemu AARCH64 RELEASE build, the size reduction is 10% before compression, 3% after compression, with the number of PE/COFF fixups reduced by 80% (see below for details) Ping? Ard Biesheuvel (2): ArmVirtPkg: build our DEBUG Shell using the small code model BaseTools AARCH64: use tiny code model by default ArmVirtPkg/ArmVirt.dsc.inc| 9 + BaseTools/Conf/tools_def.template | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) Size and offset of the compressed inner FV, with the uncompressed size near the bottom, using the large code model: File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 File Offset: 0x0001C8B8 File Length: 0x0009562C File Attributes: 0x00 File State: 0xF8 EFI_FILE_DATA_VALID File Type:0x0B EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE Type: EFI_SECTION_GUID_DEFINED Size: 0x00095614 SectionDefinitionGuid: ee4e5898-3914-4259-9d6e-dc7bd79403cf DataOffset: 0x0018 Attributes: 0x0001 Type: EFI_SECTION_RAW Size: 0x000C Type: EFI_SECTION_FIRMWARE_VOLUME_IMAGE Size: 0x003FD4C4 Size and offset of the compressed inner FV, with the uncompressed size near the bottom, using the tiny code model: File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 File Offset: 0x0001BDF8 File Length: 0x000915F0 File Attributes: 0x00 File State: 0xF8 EFI_FILE_DATA_VALID File Type:0x0B EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE Type: EFI_SECTION_GUID_DEFINED Size: 0x000915D8 SectionDefinitionGuid: ee4e5898-3914-4259-9d6e-dc7bd79403cf DataOffset: 0x0018 Attributes: 0x0001 Type: EFI_SECTION_RAW Size: 0x000C Type: EFI_SECTION_FIRMWARE_VOLUME_IMAGE Size: 0x0039B484 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/2] AARCH64 tiny code model support
The AARCH64 GCC builds use the GCC large code model by default, simply because it is the code model that requires the least amount of hacking to produce code that supports the PE/COFF conversion applied by Tianocore. However, it is suboptimal in more than one way: - each symbol reference requires a PC-relative literal load (to obtain the address of the memory location that stores the address of the symbol) and 8 bytes to store the address itself, so it uses more space than necessary; - loading the symbol address may stall on the D-cache - each symbol address is an absolute address which requires fixing up by the PE/COFF loader - the large model is not recommended by the GCC developers, and not used very widely so it does not receive a lot of testing coverage. Now that we can support relative AARCH64 relocations, we can actually switch to the GCC tiny code model, which does away with the literals, and simply uses PC-relative references to refer to the symbol directly. This does impose a 1 MB size limit on modules, but this limit is exceeded only very rarely, and we can work around it by switching to the small or large model in that case. Patch #1 overrides the BuildOptions for the DEBUG Shell build to use the small model, since its size exceeds the 1 MB limit. Patch #2 sets the AARCH64 code model to 'tiny' by default. For the ArmVirtQemu AARCH64 RELEASE build, the size reduction is 10% before compression, 3% after compression, with the number of PE/COFF fixups reduced by 80% (see below for details) Ard Biesheuvel (2): ArmVirtPkg: build our DEBUG Shell using the small code model BaseTools AARCH64: use tiny code model by default ArmVirtPkg/ArmVirt.dsc.inc| 9 + BaseTools/Conf/tools_def.template | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) Size and offset of the compressed inner FV, with the uncompressed size near the bottom, using the large code model: File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 File Offset: 0x0001C8B8 File Length: 0x0009562C File Attributes: 0x00 File State: 0xF8 EFI_FILE_DATA_VALID File Type:0x0B EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE Type: EFI_SECTION_GUID_DEFINED Size: 0x00095614 SectionDefinitionGuid: ee4e5898-3914-4259-9d6e-dc7bd79403cf DataOffset: 0x0018 Attributes: 0x0001 Type: EFI_SECTION_RAW Size: 0x000C Type: EFI_SECTION_FIRMWARE_VOLUME_IMAGE Size: 0x003FD4C4 Size and offset of the compressed inner FV, with the uncompressed size near the bottom, using the tiny code model: File Name:9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 File Offset: 0x0001BDF8 File Length: 0x000915F0 File Attributes: 0x00 File State: 0xF8 EFI_FILE_DATA_VALID File Type:0x0B EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE Type: EFI_SECTION_GUID_DEFINED Size: 0x000915D8 SectionDefinitionGuid: ee4e5898-3914-4259-9d6e-dc7bd79403cf DataOffset: 0x0018 Attributes: 0x0001 Type: EFI_SECTION_RAW Size: 0x000C Type: EFI_SECTION_FIRMWARE_VOLUME_IMAGE Size: 0x0039B484 -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel