search for: relaxations

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

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,

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

...posed to the linker as relocations so it > isn't safe to change the sizes of sections in arbitrary places [*]; > does the RiscV ABI have restrictions on code-generation to allow a > linker to reduce the code-size of a code-sequence within a Section? If > there are constraints on the relaxations it might help us make a > suggestion. > > I'm assuming that if you are doing some kind of range based relaxation > you'll need something like range extension thunks (I'm working on > these right now) this means you'll probably have to do your > calculations on what...

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 < > llvm-dev at lists.llvm.org> wrote: > >> Here's an example usin...

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

...after relaxation. On Wed, Jul 12, 2017 at 2:27 AM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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. Yes, we have a working target for RISC-V in lld now (with relaxation) and is passing our internal tests. Our iterated relaxation currently makes a copy of each input section, loops over each of them to process relaxation and...

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

...> > 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 it to make it manageable again, and I'm now focusing > on > > the TLS relaxations. > > > > Thread-local variables in ELF is complicated. The ELF TLS specification > [1] > > defines 4 different access models: General Dynamic, Local Dynamic, > Initial > > Exec and Local Exec. > > > > I'm not going into the details of the spec here, but...

> 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 > > with -fpic, and Initial Exec without -fpic. > > It is more complicated than that. You can get all 4 modes with clang > > ------------------------------- >...

...ocations 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 it to make it manageable again, and I'm now focusing on the TLS relaxations. Thread-local variables in ELF is complicated. The ELF TLS specification [1] defines 4 different access models: General Dynamic, Local Dynamic, Initial Exec and Local Exec. I'm not going into the details of the spec here, but the reason why we have so many different models for the same featur...