similar to: MachineInstr sizes for ARM jumptables

In looking at the code in ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is the following condition for not creating tbb-based jump tables: // The instruction should be a tLEApcrel or t2LEApcrelJT; we want // to delete it as well. MachineInstr *LeaMI = PrevI; if ((LeaMI->getOpcode() != ARM::tLEApcrelJT &&

Hi Jakob, You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Chad On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org>wrote: > In looking at the code in > ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is > the following condition for not creating

On Jul 29, 2013, at 6:50 AM, Chad Rosier <chad.rosier at gmail.com> wrote: > Hi Jakob, > You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Sorry, no. I don't remember working with that particular bit of code. You could try digging through the commit logs. Thanks, /jakob > On Tue, Jul 23, 2013 at

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

Hi, We at Rust are using LLVM for our codegen. Since Rust version 1.19.0, which should ship in July 21st, we are using a slightly patched version of LLVM 4.0. The transition to LLVM 4.0 had been fairly pain-free on x86 (at least excluding the standard suite of assertion failures using MSVC SEH, but that's fairly under control), but we have encountered several scary bugs in ARM, most

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

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

On Dec 3, 2013, at 2:01 PM, Gary Fuehrer <gfuehrer at defiant-tech.com> wrote: > 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

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

I'll be attending the hacking session with the intent of understanding what needs to be done to improve ARMv5 Thumb support. With any amount of luck, we can start pounding away at the support. My initial understanding from the release notes are that http://llvm.org/bugs/show_bug.cgi?id=1388 has to be fixed first. Evan Cheng writes this in 2007: The proper fix is to model CC as explicit

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

Hi Joe, Not sure yet if I'll be able to make the hacking session or not, but either way, feel free to look me up at any time during the conference and I'd be happy to talk about the arm backend. Jim On Nov 16, 2011, at 7:24 AM, Joe Abbey <jabbey at arxan.com> wrote: > I'll be attending the hacking session with the intent of understanding what needs to be done to improve

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

After looking at this for a while, I do not think that this problem is NP-hard. With a finite "short branch" displacement k, I was not able to come up with a gadget that could create global constraints as would be needed to e.g. model an instance of 3SAT or vertex cover in terms of this problem. The problem is hard though. I believe that it is likely to be exponential in the "short

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

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

Dear LLVM crew, I have been writing a new LLVM backend with a very simple instruction set. moving a constant value to a register is selected as a load of the constant, with a PC-relative positive offset. Thus, the constant should be stored in .text section, after the load instruction, and offset should be computed at compile time (not link time). I struggle to find out : - how llvm handle

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

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

Hello, This problem happens in ToT under specific conditions - namely there is a big BB#671 basic block of code the just copies data from memory location to another. At the beginning of BBB#671 r0 is loaded from the jumptable in the constant pool immediately after it. Displacement from the pc in this case is #1476 which is way above magic #1020 hence the error after fixup. Both