similar to: [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,

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

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

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

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

On Feb 25, 2011, at 11:38 AM, Rafael Avila de Espindola wrote: >>> Can someone else try to reproduce this? > > I tried gcc.c from > http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the > difference is a bit more noticeable: > > -O0 -mno-relax-all > > real 0m13.182s > user 0m12.690s > sys 0m0.450s > > -O0 > > gcc.o is

>> Can someone else try to reproduce this? I tried gcc.c from http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the difference is a bit more noticeable: -O0 -mno-relax-all real 0m13.182s user 0m12.690s sys 0m0.450s -O0 gcc.o is 10932968 bytes. real 0m12.969s user 0m12.520s sys 0m0.410s gcc.o is 11410552 bytes IMHO it would still be reasonable to switch to

> 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

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

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

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

Hi Tim, Thank you for your answer. *We've fairly recently fixed a bug that looks very similar (r238680,which was well after 3.6)* If I wanted to back port that to 3.5 where should I look at? Where in the ARM backend the decision to relax an instruction is taken? *That's weird. Even with "-filetype=obj" (the bug only occurs whendirectly writing an object file)? Not that it

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

Hi, I have written a PassManager (IR) pass that seriously increases the size of the original IR code. As a result it seems that the generated machine code is incorrect (as of LLVM 3.5): The AsmPrinter generates the following instruction : adr r2, .LJTI4_0_0 when going through the MC streamer, I get a "fatal error: error in backend: out of range pc-relative fixup" . Apparently, the fixup

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

Thanks Nirav, I can confirm that this works when I do the compile with llc, but then when linking to an executable with clang (patched with http://reviews.llvm.org/D20352 and compiler-rt patched with http://reviews.llvm.org/D21612) on Linux, I'm getting something different. Here's a sample of the transcript, and what I'm seeing: --->8 clang invocation 8<--- [16-06-23 3:33:42]