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

ARM has its own pass to do this (ARMConstantIslandPass.cpp). At some point of time we'd like to rip out the branch relaxation part and make it into a target independent pass. Evan On Aug 13, 2009, at 10:02 AM, Bagel wrote: > I think I have read that there are plans to generate object code > (e.g. ELF) > directly in addition to assembly language source. If so, are there

I think I have read that there are plans to generate object code (e.g. ELF) directly in addition to assembly language source. If so, are there plans to support branch relaxation for targets which support long/short branch displacements? This is typically done in assemblers. thanks, bagel

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

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

Palm Vacations, Look At A Jamaica Vacation For Total Relaxation There is no place like Jamaica for a vacation that consists of total relaxation. After all, isn?t that what a vacation is for? Get away from the office, get away from people demanding your time, get away from customers demanding the impossible, just get away. But where you ?get away to? will have a significant impact on how you view

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test confirmed that

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

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

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

Hi, I have kept working on this and found the following (as llvm 3.5): 1) In the function MCObjectStreamer::EmitInstruction there is a check for the instruction being relaxable or not: if (!Assembler.getBackend().mayNeedRelaxation(Inst)) { EmitInstToData(Inst, STI); return; } At this stage, the instruction as been already selected to be ARM::ADR. The call to mayNeed 2015-07-07 18:06

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

I have created a small ll file to reproduce the problem. I used the intrinsic function llvm.arm.space to introduce space between the beginning of the code and the jump table. If the first argument of llvm.arm.space is higher than INT_MAX ( *2147483647)*, then the bug is hit. Lower or equal to that value, it passes. It looks like a precision issue. Does this sound familiar to someone? ; ModuleID =

Hi all, In RISC-V ISA, the range of conditional branches is within 4KiB. In current implementation, if the branch target is out of range, LLVM MC will issue an error message to tell users it could not resolve the fixup record. I have compared the result with the GNU assembler. GNU assembler will convert the branch to inverted one plus jump to make the branch possible. The range of unconditional

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

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

This sounds very similar to what PowerPC does, see: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp However, PowerPC is doing this in the compiler backend, not in the assembler. One issue is that the process must be iterative, because branches can go both forward and backward, and replacing some branch instructions with the branch pairs can then