Displaying 20 results from an estimated 2041 matches for "relaxants".
Did you mean:
relaxant
2012 Dec 05
2
[LLVMdev] questions about the mc-relax-all flag
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
2012 Dec 06
0
[LLVMdev] questions about the mc-relax-all flag
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,
2014 Nov 13
2
[LLVMdev] [RFC] TableGen help for relaxation
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
2017 Jul 11
2
[LLD] Linker Relaxation
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
2011 Feb 24
2
[LLVMdev] [MC] Removing relaxation control
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
2012 Dec 06
2
[LLVMdev] questions about the mc-relax-all flag
>
> 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
2017 Jul 11
8
[LLD] Linker Relaxation
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
2017 Jul 11
4
[LLD] Linker Relaxation
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 <
>
2018 Dec 03
5
Branch relaxation at assembler level (RISCV)
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
2020 Aug 29
0
[klibc:riscv64-enable-relax] riscv64: Make linker relaxation work and enable it
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
2012 Dec 07
2
[LLVMdev] questions about the mc-relax-all flag
> 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
2017 Jul 12
5
[LLD] Linker Relaxation
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
2012 Dec 07
0
[LLVMdev] questions about the mc-relax-all flag
>> 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
2016 Feb 27
3
Compiling for AArch64: CommandLine Error: Option 'aarch64-branch-relax' registered more than once!
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
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
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
2011 Feb 25
0
[LLVMdev] [MC] Removing relaxation control
> 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
2020 Aug 29
0
[klibc:riscv64-enable-relax] riscv64: Make linker relaxation work and enable it
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
2016 Jan 11
2
Question about relaxation in MC assembler
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
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
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
2017 Nov 08
6
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
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