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

[Jim Grosbach]

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


On Dec 5, 2012, at 10:01 AM, Eli Bendersky <eliben at google.com> wrote:

> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev