search for: relaxing

...ctly, 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 fragmen...

...s 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 sep...

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

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

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

Here's an example using the gcc toolchain for embedded 32 bit RISC-V (my HiFive1 board): #include <stdio.h> int foo(int i){ if (i < 100){ printf("%d\n", i); } return i; } int main(){ foo(10); return 0; } After compiling to a .o with -O2 -march=RV32IC we get (just looking at foo) 00000000 <foo>: 0: 1141 addi sp,sp,-16

By the way, since this is an optional code relaxation, we can think about it later. The first thing I would do is to add RISC-V support to lld without code shrinking relaxations, which I believe is doable by at most a few hundreds lines of code. On Wed, Jul 12, 2017 at 3:21 AM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jul 11, 2017 at 9:14 PM, Bruce Hoult via llvm-dev < >

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

> E.g. -mrelax-all is either harmful or not improving enough to give a > measurable improvement. > > Can someone else try to reproduce this? I can. I tried these builds on tmpfs so as to give -mno-relax-all an smaller advantaged for less IO: --enable-optimized --with-optimize-option=-O0 real 3m38.568s user 24m15.097s sys 1m33.550s clang is 69661804 bytes --enable-optimized

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