Relation between separate ASM files and optimisations

[VinzC]

Hi people.

The title would have been «Understanding the relation between separate ASM files and optimisations».

I'm asking this in the context of cross-compiling for the AVR platform but it's about a behaviour I noticed more generally.

In projects that combine C, C++ and assembly files (.S), I noticed no optimisation are applied to the latter. What I'm referring to is, for instance compared with inline assembly instructions with asm volatile, in which case GCC may happen to reorder instructions, change registers, inline functions or even eliminate useless instructions/code paths, that doesn't seem to happen with external assembly files. Assuming my observations are correct (and I am not so sure about that, hence I'm asking), is there a way to apply optimisations to external assembly source files?

As an illustration, here are my compilation flags, as to the relevant parts:

Code: Select all

CFLAGS = -Os -fshort-enums -Wno-error=narrowing  -ffreestanding -mrelax -ffunction-sections -fdata-sections -flto -pipe
ASFLAGS = -x assembler-with-cpp $(CFLAGS)   # <-- copy CPU, F_CPU and -g if present

and here's the only example I can show of a function that never seemed to be optimised whatsoever:

Code: Select all

#include <avr/io.h>

#if defined(SPMCSR) && (defined(RSIG) || defined(SIGRD))

#if !defined(SIGRD)
#define SIGRD	RSIG
#endif

#define __BOOT_SIGROW_READ	(_BV(SPMEN) | _BV(SIGRD))
#define __SPMCSR			_SFR_IO_ADDR(SPMCSR)
#define __SIGADDR			0

.section .text

;
; Arguments: r25:r24 = pointer to the data structure
;   (See https://www.avrfreaks.net/forum/gcc-calling-conventions)
;
; Problems:
; 1) implies a `call`,
; 2) not inlined, ever,
; 3) not optimised in general!...
;

.global _read_signature
_read_signature:
	movw r26, r24		; Transfer the input pointer to the X register pair (destination)

	ldi r30, lo8(__SIGADDR)
	ldi r31, hi8(__SIGADDR)

	ldi r24, __BOOT_SIGROW_READ

	out __SPMCSR, r24	; Prepare loading from program memory
	lpm r0, Z+
	st X+, r0
	adiw r30, 0x1		; Advance the source pointer one byte further as signature bytes
						; are located at even adresses.
	out __SPMCSR, r24	; Let's repeat this two more times (3 bytes to read/store)
	lpm r0, Z+
	st X+, r0
	adiw r30, 0x1

	out __SPMCSR, r24
	lpm r0, Z
	st X, r0

	ret

#endif

This is just one example, of course. I don't exclude the flags I set are responsible for the observations I've mentioned.

Thanks in advance anyway for your insight.

[Hu]

Assembly files are input directly to the assembler. Optimization is a set of passes performed by the C/C++ compiler to help it generate the best possible assembly for what your C source tries to do. Generally, assembly files have too little context for an optimizer to be effective. For example, if you want it to inline this function, how does it know where the function stops? How does it cope with any internal labels, and decide whether to duplicate them or point them to a single instance?

If you want your code to be optimized, write it in C, so the compiler can understand what parts are needed.

[VinzC]

Thanks a lot, Hu. That makes perfect sense. I guess link-time optimisations depend on how instructions in the source file are "tagged" (for lacking a better term) and I saw no such optimisation flag for ASM. But your explanations highlight it all.

Peace

[Hu]

Link Time Optimization can be a boon for some programs, but it is fundamentally about giving the compiler visibility of the entire program, across dozens or hundreds of source files.[1] However, it is still bound by the limitation that it needs a sufficiently high level representation that it can see what the program is trying to do. In theory, someone could write an optimizer that tries to read through an assembly program, identify dead stores, opportunities to hoist loads, and so on. In practice, there is a perception that if the program was written in assembly, it's because the logic is so sensitive that the author would have invested the manual effort to micro-optimize it already, and so an optimizer trying to reconstruct intent would at best find nothing to do. It's possible that an author would write in assembly and not write the code optimally, but it feels unlikely to me that someone willing to work in assembly would do less than their best, and similarly unlikely that a program trying to derive intent could substantially improve on the assembly when it cannot even see all the assumptions that the author considered in making the choices.

[1]: gcc's LTO claims that since it optimizes the GIMPLE that results from reading C, that you can apply LTO to any set of source files that the compiler can transform into GIMPLE, including mixing supported languages.