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.
Hi Eli,
It's more of a debugging tool and stress test of the x86 branch relaxation than anything. It's definitely not intended to be an optimization.
"relax-all" says to not just relax instructions that are strictly required, but to relax every instruction that can be relaxed, whether it's needed or not.
I'm more inclined to remove the command line options entirely, especially the clang one.
-Jim
It's more of a debugging tool and stress test of the x86 branch relaxation than anything. It's definitely not intended to be an optimization.
"relax-all" says to not just relax instructions that are strictly required, but to relax every instruction that can be relaxed, whether it's needed or not.
I'm more inclined to remove the command line options entirely, especially the clang one.
Hi Jim,
I agree that relax-all will cause all instructions to be relaxed, even
those where the fixup doesn't require it. However, I would like to
challenge the statement that this isn't an optimization. In the link I
posted earlier, Chris and Daniel oppose to removing relax-all
precisely because it makes the assembler run faster.
Had it only been a stress test, removing it would be very reasonable
since at this point I assume the MC assembler is considered to be
stable.
Eli
Hi Jim,
I agree that relax-all will cause all instructions to be relaxed, even
those where the fixup doesn't require it. However, I would like to
challenge the statement that this isn't an optimization. In the link I
posted earlier, Chris and Daniel oppose to removing relax-all
precisely because it makes the assembler run faster.
Had it only been a stress test, removing it would be very reasonable
since at this point I assume the MC assembler is considered to be
stable.
I think you are right about it being an optimization (compile time
optimization to be precise). In fact, it is used by default at -O0,
run "clang -c test.c -v" and you will see -mrelax-all being passed,
but not if you add -O1.
It is not used on optimized builds because it produces larger binaries.
Eli
Cheers,
Rafael
I think you are right about it being an optimization (compile time
optimization to be precise). In fact, it is used by default at -O0,
run "clang -c test.c -v" and you will see -mrelax-all being passed,
but not if you add -O1.
It is not used on optimized builds because it produces larger binaries.
Yep. So if we intend to keep it around I propose to rename it to
-mc-optimize-relaxation, or -mc-fast-relaxation or something of the
sort (I think that the flag is obscure enough to deserve a long,
verbose and descriptive name).
Eli
It is not used on optimized builds because it produces larger binaries.
Yep. So if we intend to keep it around I propose to rename it to
-mc-optimize-relaxation, or -mc-fast-relaxation or something of the
sort (I think that the flag is obscure enough to deserve a long,
verbose and descriptive name).
So, normally "optimize" in a compiler means "produce better code", not
"produce code faster", so -mc-optimize-relaxation would be more
confusing IMHO.
A relaxation in an assembler is the act of replacing an instruction
with a more generic one. An add that takes a 8 bit immediate with one
that takes a 32 immediate for example. For that reason I think the
current name is fine: the option makes the assembler relax every
instruction it can to the most generic available. This produces larger
code, but the assembler doesn't spend time figuring out if the more
specific version works or not.
Eli
Cheers,
Rafael
It is not used on optimized builds because it produces larger binaries.
Yep. So if we intend to keep it around I propose to rename it to
-mc-optimize-relaxation, or -mc-fast-relaxation or something of the
sort (I think that the flag is obscure enough to deserve a long,
verbose and descriptive name).
So, normally "optimize" in a compiler means "produce better code", not
"produce code faster", so -mc-optimize-relaxation would be more
confusing IMHO.
Yep. This is exactly why I disagree with calling this an optimization. 
In any case, I still want to get rid of the command line option entirely. If there are cases where we want to enable the behavior for compile time performance (-O0), then that should happen automatically. We don't need or want a ton of micro-tuning knobs on the compiler command line.
-Jim