search for: armconstantislands

...have access to the source for the .bc I am trying to guess the kind of code that created the problem. So far I was able to replicate the one large basic block but I not sure how to produce the constant pool with the jumptable like in the description below. > > There have been lots of bugs in ARMConstantIslands where it's off by > 1, but I haven't seen one where it's off by a lot like this. The big offset is due to this one large basic block and is not a problem with alignment or any off by 1 issue. > > On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote: > >> Hello, >...

..., <jt#0>; mem:LD4[JumpTable]* So basically I want to catch the pattern with the possible simplification using the shifter, but I'm not even sure that I am looking into this issue at the right optimization level. Maybe this idea should be implemented in a higher level, or as a fixup in ARMConstantIslands, like the Thumb jumptable optimizations mentioned in the Bugzilla issue. I hope someone more familiar with this part of the backend can give me some pointers about how to proceed with this idea ( or why it is complete rubbish in the first place :) ) Best regards, Gabor Ballabas Software Develo...

...? > > I would do it but I am in a bit of a pickle as the .bc is from > propriety code and > I can not post it. Can't help much then. You might look into obfuscating the code, some companies are OK with distributing obfuscated IR. -debug-only=arm-cp-islands will show you what ARMConstantIslands is thinking pretty well. > Anyway, I have been trying to re-create the problem in a simpler > test case. > Since, I do not have access to the source for the .bc I am trying to > guess > the kind of code that created the problem. So far I was able to > replicate > the o...

Hi llvm developers, I might be overlooking something, but I think the ARMConstantIsland pass uses the wrong size for the MachineInstrs representing jump tables: Currently, there is the following calculation in doInitialJumpTablePlacement (lib/Target/ARM/ARMConstantIslandPass.cpp:588): ---------------------------------------------------------------------- unsigned Size = JT[JTI].MBBs.size() *

...Both ARMCodeEmitter::emitLEApcrelJTInstruction() and emitJumpTableAddress() are responsible for the offending instruction adr r0, #.LJTI8485_1_1 But besides the fact that they do not complain about the invalid offset from the pc I do not see anything wrong here. The problem seems to be in the ARMConstantIslands which is not splitting BB#671 into smaller pieces and thus producing over the limit 'add' opcode. This code fragment below is produced from a rather large bitcode file that resists being reduced to something more manageable. As a result keystrokes in gdb are very "expensive " a...

...ixupUnconditionalBr - Fix up an unconditional branch whose destination is /// too far away to fit in its displacement field. If the LR register has been /// spilled in the epilogue, then we can use BL to implement a far jump. /// Otherwise, add an intermediate branch instruction to a branch. bool ARMConstantIslands::fixupUnconditionalBr(ImmBranch &Br) { MachineInstr *MI = Br.MI; MachineBasicBlock *MBB = MI->getParent(); if (!isThumb1) llvm_unreachable("fixupUnconditionalBr is Thumb1 only!"); // Use BL to implement far jump. Br.MaxDisp = (1 << 21) * 2; MI->setD...

I can look at this, but you'll need to send the .bc file. Please open a PR? There have been lots of bugs in ARMConstantIslands where it's off by 1, but I haven't seen one where it's off by a lot like this. On Aug 17, 2010, at 7:53 PMPDT, Pawel Wodnicki wrote: > Hello, > > This problem happens in ToT under specific conditions - namely there > is > a big BB#671 basic block of code > the ju...

...ix up an unconditional branch whose destination is > /// too far away to fit in its displacement field. If the LR register has been > /// spilled in the epilogue, then we can use BL to implement a far jump. > /// Otherwise, add an intermediate branch instruction to a branch. > bool > ARMConstantIslands::fixupUnconditionalBr(ImmBranch &Br) { > MachineInstr *MI = Br.MI; > MachineBasicBlock *MBB = MI->getParent(); > if (!isThumb1) > llvm_unreachable("fixupUnconditionalBr is Thumb1 only!"); > > // Use BL to implement far jump. > Br.MaxDisp = (1 <<...

Hello, I’m writing machine function passes for programs running with ARMv7-M ISA. My pass adds some instructions to the original code, and now I got fatal error: error in backend: out of range pc-relative fixup value when llvm generates native code after running the transformation pass. I think it’s because my transformation pass increases the size of the original code and thus some branch

...al branch whose destination is >> /// too far away to fit in its displacement field. If the LR register has been >> /// spilled in the epilogue, then we can use BL to implement a far jump. >> /// Otherwise, add an intermediate branch instruction to a branch. >> bool >> ARMConstantIslands::fixupUnconditionalBr(ImmBranch &Br) { >> MachineInstr *MI = Br.MI; >> MachineBasicBlock *MBB = MI->getParent(); >> if (!isThumb1) >> llvm_unreachable("fixupUnconditionalBr is Thumb1 only!"); >> >> // Use BL to implement far jump. &gt...

Hi I am developing some machine function pass. I want to split MachineBasicBlcok when I find some specific machine instruction. But I don't insert or delete any machine instruction. I just "simply" , "purely" split the MachineBasicBlcok. (So, I stole the idea from ARM64BranchRelaxation::splitBlockBeforeInstr.) This is my code : // I would pass call instruction to

Hi, I'm building a new backend which can only load very limited range of imm. So I decided to use constant pool, and place constant pool entries close enough to instructions use the entries (we have very limited range PC-relative memory load). However, lld & llc output the object files that gather all constant pool entries into one section. How can I make them mix these entries into code

...tice; I mean, I guess > it's an issue in theory, but in practice we don't stick branches into > the middle of basic blocks. I did not expect a branch in the middle of a basic block either, until yesterday LLVM Release 4.0.0 produced the following machine basic block before the pass ARMConstantIslands is run: bb.1.if.end: successors: %bb.3.for.body(0x80000000) liveins: %r4 %r0 = tMOVr %r4, 14, _, debug-location !23 tBL 14, _, $__aeabi_i2d, csr_aapcs, implicit-def dead %lr, implicit %sp, implicit %r0, implicit-def %sp, implicit-def %r0, implicit-def %r1, debug-location !23...

...of two of his commits dealt with substituting MOVW/MOVT pairs > for an LDR and a lit-pool. Isn't this what MachineConstantPool and > ARMConstantIslandPass was all about? Both are essential components to using lit-pools: the MachineConstantPool is just LLVM's underlying machinery and ARMConstantIslands is for fixing up out of range loads and so on so they can actually be used. My recent changes have been to fix Darwin CodeGen so that they're actually useful (previously we combined movw/movt pairs referring to the same global but not litpool ones, which meant that litpools actually took up mo...

Today I updated to trunk the toolchain for my work developing on Cortex-M4F. I was super excited to see three commits by Tim Northover that actually attempt to improve the machine code generation for my target, or any ARM target for that matter (as opposed to other important work on compiler correctness or architectural elegance or formatting comment white-space, I mean). Is he alone or are

I have legit requirement to keep the switch generated lookup table in function section. The lookup table is being generated in SimplifyCFG pass and is treated as a global. Is there a good way to mark these lookup tables and recognize them later to keep them in function sections. --Sumanth -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

> The right way to update the CFG very much depends on how you're > transforming it. I would like to export the CFG for control flow checking. Theoretically, it should be possible for a compiler to know every target of every control flow instruction, except for computed targets that are not known at compile-time. When a machine basic block is split between two branches, as shown below: