C → Assembly: Otimizações, Volatile e o que o compilador pode fazer

Author: Marcos Azevedo

Date: 2026-01-20

Last Modified: 2026-01-20

Reading Time: 5 mins

Section: Series

Categories: series

Tags: c-lang programming risc-v

TL;DR

Você vai entender como o compilador transforma C em assembly e por que o mesmo C pode parecer totalmente diferente entre -O0 e -O2.
Vai construir um modelo mental prático para:
- eliminação de código morto,
- eliminação de subexpressões comuns,
- inlining,
- alocação de registradores,
- e como volatile limita essas otimizações.
Vai rodar experimentos e validar resultados com objdump e GDB.

1. O pipeline do compilador (por que existem várias “traduções”)

flowchart TD
  A["C source (.c)"] --> B["Frontend to IR (Intermediate Representation)"]
  B --> C["Optimizer (depends on -O level)"]
  C --> D["Backend to assembly (.s)"]
  D --> E["Assembler to object (.o)"]
  E --> F["Linker to ELF (.elf)"]

Duas consequências:

“O compilador” não é um passo só; são várias etapas.
-O muda a etapa de otimização, que muda tudo adiante.

Important

Se você não entende otimização, vai interpretar errado disassembly e sessões de debug, especialmente quando variáveis “somem” ou o fluxo de controle não parece nada com o seu C.

2. Laboratório prático: um programa, vários níveis de otimização

Crie:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// src/opt.c
#include "types.h"
#include "uart.h"

volatile u32 sink;

u32 f(u32 x) {
  u32 a = x * 3u;
  u32 b = x * 3u;      // mesma expressão de a
  u32 c = a + b;

  if ((c & 1u) == 0u) {
    // parece que importa...
    c += 10u;
  }

  // armazena o resultado em algum lugar observável
  sink = c;
  return c;
}

int main(void) {
  u32 r = f(7u);
  uart_puts("f(7)=");
  uart_puthex32(r);
  uart_putc('\n');
  return 0;
}

Compile duas variantes:

1
2
3
4
5
riscv64-unknown-elf-gcc -g -ffreestanding -nostdlib -march=rv32im -mabi=ilp32 -O0 \
  -T src/link.ld src/start.s src/uart.c src/opt.c -o build/opt_O0.elf

riscv64-unknown-elf-gcc -g -ffreestanding -nostdlib -march=rv32im -mabi=ilp32 -O2 \
  -T src/link.ld src/start.s src/uart.c src/opt.c -o build/opt_O2.elf

Rode os dois:

1
2
3
4
5
// Execute, verifique a saída e use CTRL+a x para sair do qemu;
qemu-system-riscv32 -M virt -nographic -bios none -kernel build/opt_O0.elf

// Execute, verifique a saída e use CTRL+a x para sair do qemu;
qemu-system-riscv32 -M virt -nographic -bios none -kernel build/opt_O2.elf

Faça o disassembly de ambos:

1
2
3
riscv64-unknown-elf-objdump -d -M numeric,no-aliases build/opt_O0.elf | less

riscv64-unknown-elf-objdump -d -M numeric,no-aliases build/opt_O2.elf | less

O que observar

Em -O0:
- mais uso de pilha,
- mais loads/stores,
- variáveis “vivem” como você espera.
Em -O2:
- a e b provavelmente são calculados uma vez,
- branches podem ser simplificados,
- o código pode ser reorganizado.

Tip

Ao aprender assembly, comece com -O0 e depois aprenda a reconhecer as formas otimizadas.

3. Por que variáveis somem em builds otimizadas

Alocação de registradores

Em -O2, o compilador tenta manter valores em registradores e pode nunca materializá-los na memória.

Encolhimento de vida útil

Se o valor de uma variável é usado só por um instante, ela pode nunca existir como um local nomeado.

Inlining

Funções pequenas frequentemente são substituídas pelo seu corpo.

Note

É por isso que o GDB mostra <optimized out> para algumas variáveis.

4. volatile significa “deve realizar o acesso”

Um objeto volatile diz ao compilador:

toda leitura é um load real,
toda escrita é um store real,
o compilador não pode remover nem combinar esses acessos,
o compilador não pode assumir que o valor permanece o mesmo entre acessos.

Isso é crítico para:

registradores MMIO (Memory-Mapped I/O),
estado compartilhado com ISR (Interrupt Service Routine),
memória modificada externamente.

Na prática: volatile vs não-volatile

Crie:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// src/volatile_demo.c
#include "types.h"
#include "uart.h"

u32 nv_reg;
volatile u32 v_reg;

u32 demo(u32 x) {
  nv_reg = x;
  nv_reg = x;     // pode ser fundido

  v_reg = x;
  v_reg = x;      // não pode ser fundido

  return nv_reg + v_reg;
}

int main(void) {
  u32 r = demo(0x1234u);
  uart_puts("demo=");
  uart_puthex32(r);
  uart_putc('\n');
  return 0;
}

Compile otimizado e faça o disassembly:

1
2
3
riscv64-unknown-elf-gcc -g -ffreestanding -nostdlib -march=rv32im -mabi=ilp32 -O2 \
  -T src/link.ld src/start.s src/uart.c src/volatile_demo.c -o build/vol_O2.elf
riscv64-unknown-elf-objdump -d -M numeric,no-aliases build/vol_O2.elf | less

O que você deve observar:

O double-store não-volatile pode virar um único store.
O double-store volatile deve permanecer com dois stores.

Warning

volatile não é um primitivo de sincronização. Ele não cria atomicidade, nem garante ordenação entre núcleos, nem cria barreiras de memória. Para concorrência, use atômicos C11 ou fences explícitos.

5. Mapeando C de volta para assembly (um método prático)

Quando você vê assembly, pergunte:

Onde estão as entradas? (normalmente a0..a7)
Onde o valor de retorno vai? (normalmente a0)
Quais registradores precisam sobreviver a chamadas? (callee-saved s*)
Quais stores na memória são observáveis? (volatile, globais, chamadas de função)

Use o assembly gerado pelo compilador como “ponte”

Gere saída .s:

1
2
riscv64-unknown-elf-gcc -S -O0 -ffreestanding -nostdlib -march=rv32im -mabi=ilp32 -o build/opt_O0.s src/opt.c
riscv64-unknown-elf-gcc -S -O2 -ffreestanding -nostdlib -march=rv32im -mabi=ilp32 -o build/opt_O2.s src/opt.c

Compare build/opt_O0.s e build/opt_O2.s.

Tip

O arquivo .s costuma ser mais fácil de ler do que o objdump, porque preserva rótulos e estrutura.

Exercícios

Modifique opt.c para que sink não seja volatile. Preveja o que muda em -O2.
Adicione um uart_putc (ou qualquer chamada externa) e observe como ele “ancora” valores (chamadas são barreiras de otimização).
Escreva duas funções: uma pequena, outra grande. Observe quando a pequena é inlined.

Como testar suas respostas

Use objdump -d -M numeric,no-aliases para comparar sequências de instruções.
Use readelf -s para ver se funções ainda existem como símbolos (o inlining pode remover o símbolo).

Resumo

Você aprendeu o que as otimizações fazem, por que depurar código otimizado pode ser confuso, e o que volatile realmente garante.

A seguir: fluxo de controle e acesso a dados, você vai ver como if/loops/switch viram branches e jump tables, e como loads/stores codificam endereçamento.