similar to: [LLVMdev] ToT ARM Code generator causing - Error: invalid constant (xxx) after fixup in assembly output

On 8/18/2010 12:39 PM, Dale Johannesen wrote: > I can look at this, but you'll need to send the .bc file. Please open > a PR? 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. 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

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

On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote: > On 8/18/2010 12:39 PM, Dale Johannesen wrote: >> I can look at this, but you'll need to send the .bc file. Please >> open a PR? > > 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

Hi All, I started to work on code-size improvements on ARM target by comparing GCC and LLVM generated code. My first candidate was switch-case lowering. I also created a Bugzilla issue for this topic: https://bugs.llvm.org/show_bug.cgi?id=34902 The full example code and the generated assembly for GCC and for LLVM is in the Bugzilla issue. My first idea was to simplify the following

I don't know ARM hardly at all but... This comment does not seem to match the code. Or maybe tBfar is a BL? Also, how does this work if the destination is greater than 2**21? /// fixupUnconditionalBr - 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

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() *

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

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

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

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

Thank you for your reply! > Every MachineBasicBlock has a list of successors; you can access it with > the successors() accessor. That's what you should be using for any CFG > analysis. I am aware of these methods of class MachineBasicBlock, which allows one to access a MachineBasicBlock's successors and predecessors in the CFG. But the CFG itself may no longer be valid if a

Hi Gary, On 3 December 2013 22:01, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > The subject 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

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: