[LLVMdev] questions about the mc-relax-all flag

Eli Bendersky eliben at google.com
Wed Dec 5 10:01:39 PST 2012


Hello,

In llc, we have this flag (output of command --help | grep relax):
  -mc-relax-all     - When used with filetype=obj, relax all fixups in
the emitted object file

It also appears in clang:
  -mrelax-all       (integrated-as) Relax all machine instructions

I'd like to discuss the naming and semantics of this flag, because
ISTM at least the name is misleading.

If I understand correctly, relaxation is always required in MC (*) to
produce correct code, and in fact MC always performs relaxation,
whether mc-relax-all was passed or not. What mc-relax-all seems to
affect is how certain decisions in MC are handled. Specifically:

* Whether MC tries to understand if a fixup requires relaxing prior to
deciding to relax an instruction. mc-relax-all overrides this decision
and MC always tries to relax an instruction (unless it's
architecturally not needing relaxation).
* Whether MC tries to relax an instruction directly and emit it as
data or emits it in a separate instruction fragment, where it will be
relaxed later.

In light of this, and unless I missed something obvious, mc-relax-all
is an optimization. A previous discussion from roughly two years ago -
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-February/038302.html -
confirms this, also showing that this optimization can be beneficial.
So the questions are:

1. Should it not be always enabled? Why would we want to disable it?
2. Could a better name be conjured for it? As it stands now, the flag
sounds like a binary predicate - either relax all, or don't relax all.
Maybe something like "mc-early-relaxation" would be more descriptive?

Thanks in advance for any insights,
Eli

(*) For instance in the case of X86, the MCInst emitter shrinks JNE_4
to JNE_1 counting on relaxation in the assembler to fix it if needed.



More information about the llvm-dev mailing list