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 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
> > 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