search for: relaxed

...o 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 qu...

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

Hello LLVM, My target has a complex relaxation hierarchy. Perhaps a modest TableGen extension would help consolidate most of the work involved in choosing a relaxed opcode. I also notice the x86 relaxation code with a comment wondering if TableGen could improve life. Does the following outline sound interesting? 1) Add a new field of type 'Instruction' to the Instruction class called "RelaxedInstr" 2) Target instructions optionally set Re...

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

Hi all, clang -O0 currently differs from -O1 and higher in passing down -mrelax-all. When compiling assembler files, this results in conditional jumps using the relaxed forms, which is surprising. Based on the discussion on IRC, I did a llvm/clang release build with -O0 for OPTIMIZER and -O0 -mno-relax-all. Result is: -O0 (-mrelax-all) 68m27.893s 254m19.920s 1m45.720s -O0 -mno-relax-all 68m6.640s 253m31.880s 1m45.310s E.g. -mrelax-all is either harmful or not...

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

...ions on what you can relax in finalizeSections() at a similar > point to createThunks(), or perhaps the mechanisms would need to be > merged as I think they'll need to converge on a point when no more > relaxations are possible and no more thunks can be added. > > Writing out the relaxed sections will be interesting as you won't want > all of the InputSectionContents. I suggest looking at EHFrame and > MergeInputSections for ideas. > > Hope that is of some use > > Peter > > [*] For example in pseudo ARM > > ldr r0, [pc, offset] ; where pc + off...

...ctions() at a similar >>> point to createThunks(), or perhaps the mechanisms would need to be >>> merged as I think they'll need to converge on a point when no more >>> relaxations are possible and no more thunks can be added. >>> >>> Writing out the relaxed sections will be interesting as you won't want >>> all of the InputSectionContents. I suggest looking at EHFrame and >>> MergeInputSections for ideas. >>> >>> Hope that is of some use >>> >>> Peter >>> >>> [*] For example i...

Hi all, I'm trying to implement the same branch relaxation mechanism implemented in CodeGen in the MC layer of RISCV.   beqz t1, L1   =>   bnez t1, L2   j L1 That's because LLVM does not apply the CodeGen optimizations when compiling directly from assembly code. What I'd like to do would be to add a pass that does that on the MC instructions or at least to find a way to

Commit-ID: 83fcb05804497482caab9a77451907f1a5a6a8e2 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=83fcb05804497482caab9a77451907f1a5a6a8e2 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 29 Aug 2020 21:59:24 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sun, 30 Aug 2020 00:48:29 +0100 [klibc] riscv64: Make linker

> 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

Hi, On Wed, Jul 12, 2017 at 2:21 AM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks, Bruce. This is a very interesting optimization. > > lld doesn't currently have code to support that kind of code shrinking > optimization, but we can definitely add it. It seems that essentially we > need to iterate over all relocations while rewriting

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

Compiling for AArch64: CommandLine Error: Option 'aarch64-branch-relax' registered more than once! Hi all! I am trying to run LDC (LLVM-based D compiler) on AArch64. The compiler contains all IR and target specific passes. You can view it as combined llc/opt tool. It uses the same strategy as opt to collect the passes with the NameParser. Like llc, it calls

On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS > access > > models, so I think we can drop TLS relaxation support from lld. > > > > lld's code to handle

...sys 2m24.325 clang is 686194963 bytes --enable-optimized --with-optimize-option="-O0 -g -mno-relax-all" real 4m58.735s user 29m34.127s sys 2m25.734s clang is 685305227 bytes > I've also did some testing with a worst case assembler file doing lots > of jumps that can all be relaxed. In that case, -mno-relax-all was 25%. > If the above observation can be confirmed, I believe there is no good > reason to keep -mrelax-all. To the best of my knowledge relaxation is more expensive on ELF than on Mach-O since there are less opportunities on Mach-O. Given that, I think it is...

Commit-ID: a966c3a12ee8b921dc669647c1fe75b25f72e604 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a966c3a12ee8b921dc669647c1fe75b25f72e604 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sat, 29 Aug 2020 21:59:24 +0100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 29 Aug 2020 23:33:09 +0100 [klibc] riscv64: Make linker

Hi All, I have a question about relaxation stuff in MC assembler. I am encoding conditional branch instructions with PC relative address in assembler. I have met some tests with relative offsets over the instruction's address field. I think I need to change the conditional instruction to multiple instructions with basic blocks for else and then syntax and it should be done in assembler

On Tue, Nov 7, 2017 at 8:16 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> So I am strongly against removing either non TLSDESC support of support > >> for the relaxations. > >> > > > > It's still pretty arguable. By default, compilers use General Dynamic > model

tl;dr: TLSDESC have solved most problems in formerly inefficient TLS access models, so I think we can drop TLS relaxation support from lld. lld's code to handle relocations is a mess; the code consists of a lot of cascading "if"s and needs a lot of prior knowledge to understand what it is doing. Honestly it is head-scratching and needs serious refactoring. I'm trying to simplify