similar to: Branch relaxation at assembler level (RISCV)

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

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

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 all, I'm currently working on the implementation for LLVM of the RISCV Bit Manipulation ISA extension described by Clifford Wolf in the following presentation: https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf and the following document: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf The aim is to provide the intrinsic functions to the user in

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

Hi Roman, > That depends. > If there's LLVM intrinsic for it, then any normal optimization pass could do it. > In cttz's case it's mainly done in LoopIdiom pass. Oh yes. Thank you! Unfortunately several of the instructions of the bit manipulation extension don't seem to have an intrinsic already in LLVM. That will require to add some passes to the middle end. >

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

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

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 =

On Fri, 2015-02-20 at 13:47 -0500, Rafael Espíndola wrote: > > Your task, should you choose to accept it, is to make it cope with other > > forms of relaxation where necessary. > > And if not, please open a bug :-) http://llvm.org/bugs/show_bug.cgi?id=22662 FWIW I could reproduce the 'movl foo, %ebx' one but a relative jump *was* using 16 bits (although gas uses 8):

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

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be

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

H all, I'm looking at generating PIC code for RISC-V in the context of Linux. Not sure if anyone is working on this already, any inputs are very welcome. I'm now looking at function calls which in the RISCV backend are represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL. Currently those pseudos are lowered in MCCodeEmitter. They are expanded into AUIPC and JALR

Hi LLVM developers, Thank Daniel Sanders, Aditya Nandakumar and Justin Bogner's Tutorial[1]: Head First into GlobalISel about how to port, and Aditya took BPF target as a simple instance: bool BPFCallLowering::lowerReturn(MachineIRBuilder &MIRBuilder,                                   const Value *Val, unsigned VReg) const {   assert(!Val == !VReg && "Return value

I notice that no intrinsics have been defined for the CSRRW/CSRRS/CSRRC instructions. It would be convenient to have intrinsics for these to allow CSR manipulation directly from IR code. Interestingly, this seems to be true for PowerPC (no intrinsics for mfdcr/mtdcr) and X86 (no in/out) as well. Are there plans to define standard RISCV intrinsics for this? -------------- next part

On 10 May 2014, at 13:53, Tim Northover <t.p.northover at gmail.com> wrote: > It doesn't make sense for everything though, particularly if you want > target-specific IR to simply not exist. What would you map ARM's > "ldrex" to on x86? This isn't a great example. Having load-linked / store-conditional in the IR would make a number of transforms related to