search for: ppcbranchselector

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 cause other branches to go out of range....

Hi Hal, Thanks for the reference. I’ve looked at PPCBranchSelector and the PowerPC backend. It is very different from the X86 architecture and unfortunately the way branch relaxation and alignment related issues are handled in PPC cannot be copied to X86. This is because: 1. PPC instructions are of fixed length while X86 instructions are of variable length,...

Hi Hal, A pre-emit pass will indeed be preferable. I originally thought of it, too, however I could not figure out how can such a pass have an access to information on instruction sizes and block alignments. I know that for X86, at least, the branch relaxation is happening during the layout phase in the Assembler, where I plan to integrate the nop insertion such that the new MCPerfNopFragment

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

...; +} How about a default GetInstSize() as well? Return 1 for every instruction except for some special TargetInstrInfo instructions, e.g. PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But perhaps we can default most targets to it? > > Index: lib/Target/PowerPC/PPCBranchSelector.cpp > =================================================================== > --- lib/Target/PowerPC/PPCBranchSelector.cpp (revision 49716) > +++ lib/Target/PowerPC/PPCBranchSelector.cpp (working copy) > @@ -22,7 +22,6 @@ > #include "PPCPredicates.h" > #include "llvm/...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

You are trying to do a few different things here, and a uniform solution may not work for all of them. For a fixed instruction sequence, e.g. a special kind of move-and-branch sequence used for tail calls, you probably want a pseudo. If you are trying to combine arbitrary instructions together, e.g. Thumb IT blocks, you probably want to use bundles, even if the sequences are a fixed length. I