Why does gcc not make use of special OP codes

[jdoubleu]

I was wondering why gcc wouldn't use specialized OP codes from the xtensa instruction set architecture (ISA).

I'm using the ESP32-WROVER-B board, which itself uses the Xtensa LX6 microprocessor. From their Overview Handbook, I learned that the Xtensa LX processor family supports some specialized extensions to their instruction set. They include "zero-overhead" loops and min/max hardware-level implementations (compare section 2.12.1 http://loboris.eu/ESP32/Xtensa_lx%20Ove ... G8.1098890). Unfortunately, I couldn't directly find out whether the ESP32 boards include these features. Neither from the comparison table in the documentation (https://docs.espressif.com/projects/esp ... rison.html) nor from the data sheet (https://www.espressif.com/sites/default ... eet_en.pdf).

However what I found were the configurations for the binutils overlays, where the loop and minmax features are enabled (compare https://github.com/espressif/xtensa-ove ... nfig.h#L71). This is true for the ESP-IDF toolchain I downloaded, as well (check

Code: Select all

$IDF_TOOLS_PATH/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/sys-include/xtensa/config/core-isa.h

). I'm not sure what

Code: Select all

xtensa_lx106

is, because it's disabled for that platform.

In theory these features should be available, but when I check the code generated from gcc, I don't see any of those op codes in the assembly listing. Even when I use the

Code: Select all

-O2

flag.

I get the following assembly for a

Code: Select all

int x = (a < b) ? a : b;

:

Code: minmax.txt Select all

# a and b are set before

#      ...

	blt	a11, a2, .L49

	bne	a2, a11, .L48

	bgeu	a10, a3, .L48

#      ...

Furthermore I only see "normal" loops with branches:

Code: loops.txt Select all

#	...

	j	.L4

.L5:

#      loop body

#      ...

.L4:

	blt	a7, a4, .L5

#      ...

[jdoubleu]

As it turns out, the compiler indeed uses these special OP codes and outputs them in at least -O2 mode. It just so appears that they're not being used in most of my functions, probably because the compiler found a better way?

The following C code:

Code: main.c Select all

static int my_min(int a, int b)

{

    return a < b ? a : b;

}



static void my_loop(int* p)

{

    for (int i = 0; i < 64; ++i)

        p[i] += 1;

}



int main()

{

    int a, b;

    std::scanf("%d\n%d", &a, &b);



    int x = my_min(a, b);



    // please don't do this ever

    my_loop(&x);



    std::printf("%d", x);

}

compiled with

Code: Select all

xtensa-esp32-elf-gcc -S -o main.s -c main.cpp -O3

yields:

Code: main.s Select all

#      ...

	l32r	a10, .LC1

	addi.n	a12, sp, 4

	addi.n	a11, sp, 8

	call8	scanf

	l32i.n	a10, sp, 4

	l32i.n	a9, sp, 8

	mov.n	a8, sp

	min	a9, a9, a10

	s32i.n	a9, sp, 0

	movi.n	a10, 0x40

	loop	a10, .L2_LEND

.L2:

	l32i.n	a9, a8, 0

	addi.n	a9, a9, 1

	s32i.n	a9, a8, 0

	addi.n	a8, a8, 4

	.L2_LEND:

	l32i.n	a11, sp, 0

	l32r	a10, .LC3

	movi.n	a2, 0

	call8	printf

	retw.n

#      ...

As you can see, it includes the min and loop instructions.

[boarchuz]

https://github.com/espressif/esp-idf/bl ... 1404-L1413

[jdoubleu]

https://github.com/espressif/esp-idf/bl ... 1404-L1413

Interesting. The zero-overhead loop is already very constrained in terms of application. There are only few cases where this loop can be used anyways.