search for: thumb1

Hi Eli, Thanks for your response. Actually, I look a lot at the ARM and THUMB1 backend implementations, and this certainly help. My architecture also have specific instructions for SP-relative accesses in a similar way than the Thumb1. During frame lowering, specific machine instructions are emitted so there’s no issue there. Also during ISelDagToDag I am able to select the...

...le with Cortex-M0 (from a virtualised testing perspective) is > that it doesn't have an MMU, so any "real" operating system > environment will be far more artificial than we'd like, and probably > very low down on qemu's list of priorities to boot. > > Testing a Thumb1 CPU with an MMU (I'm sure there are ARM11* CPUs with > MMU but before Thumb2, but would need to dig into which is closest to > v6m) would cover *most* issues, but obviously not the ways in which > Cortex-M0 is closer to v7 than v6. Why not test on real hardware? https://developer.mbe...

Hello, as a newbee, I'd appreciate some support on regression test setup. Specifically, I am interrested in the feature of tail call optimizations for the ARM v6m targets. This feature currently seems to be completely deactivated at the moment (v6m being based on thumb1 ?!). According to my code-reading, this feature will involve some modifications in epilogue generation. My work on a gcc backend did show me that for a beginner like me, it is rather likely that the first attempts will break something. Thus, being completely new to the llvm project I think that i...

...hink that would be a good step forward. It would also allow > to get a buildbot going without too much effort continuously checking > basic correctness of v6m code generation. > > My guess is that the biggest hurdle would be to get linux or a similar > operating system going on a v6m/thumb1 simulator. Does anyone have an idea > if this is feasible or completely impossible? I'm working on a baremetal cross toolchain, and I would like to set up such a buildbot. There are several pieces needed before that can happen though, and the important one is remote testing support in LIT...

Am 19.12.2014 11:00, schrieb Renato Golin: > On 18 December 2014 at 04:02, Tim Northover <t.p.northover at gmail.com> wrote: >>> You have some special version of qemu? My default distribution's qemu >>> package did not have a cortex-M0 nor has qemu head freshly taken from git: >> The trouble with Cortex-M0 (from a virtualised testing perspective) is >>

Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a...

> > $ qemu-arm -cpu ? > > Available CPUs: > > arm926 arm946 arm1026 arm1136 arm1136-r2 arm1176 arm11mpcore > > cortex-m3 > > cortex-a8 > > cortex-a8-r2 cortex-a9 cortex-a15 ti925t pxa250 sa1100 sa1110 > pxa255 pxa260 > > pxa261 pxa262 pxa270 pxa270-a0 pxa270-a1 pxa270-b0 pxa270-b1 xa270- > c0 > > pxa270-c5 any > > >

In MyTargetRegisterInfo.td file, I defined separated register classes for general purpose registers and for the SP register: def GR16 : RegisterClass<"CPU74", [i16], 16, (add R0, R1, R2, R3, R4, R5, R6, R7)>; def SSP : RegisterClass<"CPU74", [i16], 16, (add SP)>; The SP can not be used in general purpose arithmetic instructions, therefore I defined the following

What about benchmarks on other Arm devices? On 02/26/2013 02:52 PM, Jim Grosbach wrote: > Cortex-M0 is a Thumb1 only device. There hasn't been any concerted > effort to tune LLVM's Thumb1 output in quite a long time. Even back then > (2008 or so), the effort was mainly to get it to work acceptably, with > the real performance tuning work being done for Thumb2. I'm not > surprised that...

...> implementation does) >> >> Since LR is not preserved, the following JMP(lr) results in an endless loop. >> >> Or is this an intentional change of the behavior? > Hi Peter, > > That is most certainly a bug. Weiming's patch was supposed to only > introduce Thumb1 code, not transform div0 into a busy loop. :) > > >> The file contains another implementation enabled by __ARM_ARCH_EXT_IDIV__. >> This uses "b" instead of "bl". >> (This works as in previous versions) > The comment on the patch makes that clear: >...

...t; I guess I can just fix the problem with: > > if ((RC == &Mips::CPU16RegsRegClass) && > !TM.getSubtargetImpl()->inMips16Mode()) > RC = &Mips::CPURegsRegClass; Can I ask what concrete problem you're seeing? The ARM backend has exactly the same issue: in Thumb1 mode (similar to MIPS16), not all GPRs are available. Accordingly, getMinimalPhysRegClass() returns tGPR (Thumb GPR) for those registers that are accessible in Thumb1 mode. What Jakob's trying to tell you here, and which works in practice for the ARM backend, is that this shouldn't matter...

Cortex-M0 is a Thumb1 only device. There hasn't been any concerted effort to tune LLVM's Thumb1 output in quite a long time. Even back then (2008 or so), the effort was mainly to get it to work acceptably, with the real performance tuning work being done for Thumb2. I'm not surprised that an embedded market...

On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 2:28 PM, reed kotler wrote: > >> I'm not using getMinimalPhysRegClass. Some target independent code is using it. > Probably PEI. > >> It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this

Hi, I didn't do any serious benchmarking but so far I never found a case where LLVM does better than IAR on CortexM0, but I saw a lot of cases where IAR output is better than LLVM... That said I did not use -Os or -Oz, I just used -O3. A recurrent situation is that LLVM push/pop one or two extra registers compared to IAR, I guess it does so in order to comply with a standard ABI or

...due to licensing issues, so I don't have a good feel for comparative benchmarking. -Jim On Feb 26, 2013, at 4:20 PM, Reed Kotler <rkotler at mips.com> wrote: > What about benchmarks on other Arm devices? > > On 02/26/2013 02:52 PM, Jim Grosbach wrote: >> Cortex-M0 is a Thumb1 only device. There hasn't been any concerted >> effort to tune LLVM's Thumb1 output in quite a long time. Even back then >> (2008 or so), the effort was mainly to get it to work acceptably, with >> the real performance tuning work being done for Thumb2. I'm not >&gt...

...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->setDesc(TII->get(ARM::tBfar)); BBInfo[MBB->getNumber()].Size += 2; adjustBBOffsetsAfter(MBB); HasFarJump = true; ++NumUBrFi...

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

Hi Yvan, On Mon, 5 Nov 2018 at 10:11, Yvan Roux via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Yes, I'll submit an RFC soon, my prototype works fine but I still have > a couple issues to tackle (some Thumb1 corner cases, PIC code > generation, ...) and enhance the testsuite. Any news on this? I'm starting to look into 32-bit ARM outlining too and could probably help out with some of those corner cases. Cheers. Tim.

...o do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t (specifically, thumb1) is limited in that it cannot copy from lo register to lo register, but the register allocator assumes it can do whatever it wants. This means that copies get emitted which don't work on that architecture, leading to broken code even for trivial cases like: "void foo(int a, int b) { bar(b,...

...bility, which gcc has, to have mips16 and mips32 functions in the same source module, so with that capability, this other work was nearly trivial. This pass I wrote is very easy to understand if you understand the underlying issues it is addressing. Arm does not have this ability to compile both thumb1 and ARM functions in the same source file in LLVM so they would not have had the option to do this in the IR. This mips16 and mips32 floating point interoperability is very complicated and has many cases, compounded by messy issues with endian, static/pic. Mips16 has no floating point but the...