search for: thumb1instrinfo

...e, but it will probably be a a while before I come back to this. Hopefully this thread serves as a nice bread-crumb for anyone who is interested) Cheers, Jon -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded -------------- next part -------------- Index: lib/Target/ARM/Thumb1InstrInfo.cpp =================================================================== --- lib/Target/ARM/Thumb1InstrInfo.cpp (revision 436473) +++ lib/Target/ARM/Thumb1InstrInfo.cpp (revision 437773) @@ -1,67 +1,82 @@ //===-- Thumb1InstrInfo.cpp - Thumb-1 Instruction Information -------------===// // //...

...e working on https://reviews.llvm.org/D79785, we wanted to define foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by TargetInstrInfo::foldMemoryOperand, which is done unconditionally: // Copy the memoperands from the load to the folded instruction. if (MI.memoperands_empty()) { NewMI->setMemRefs(MF, LoadMI.memoperands()) In this case, we don&...

...ews.llvm.org/D79785, we wanted to define > foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call > to direct call tLDRpci, tBLX -> tBL. This triggered an assertion > error with expensive checks turned on in MachineVerifier because the > newly created tBL insn by > Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI > attached by TargetInstrInfo::foldMemoryOperand, which is done > unconditionally: > > // Copy the memoperands from the load to the folded instruction. > if (MI.memoperands_empty()) { > NewMI->setMemRefs(MF, LoadMI.memoperan...

...9;s kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >> > > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. > > If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > >> Maybe I'm shooting myself in the foot there. I don&...

...se SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > Maybe I'm shooting myself in the foot there. I don't know that c...

...kward but does work except in this case of load/store haflword and byte to stack objects. >>> >> >> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >> >> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >> >>> Maybe I'm shooting myself in the...

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are

...does work except in this case of load/store haflword and byte to stack objects. >>>> >>> >>> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >>> >>> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >>> >>>> Maybe I'm shooting...

...To: John Brawn <John.Brawn at arm.com> > Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [ARM] Register pressure with -mthumb forces register reload before each call > > Hi, > I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. > For the following case: > > void f(int x, int y, int z) > { > void bar(int, int, int); > > bar(x, y, z); > bar(x, z, y); > bar(y, x, z); > bar(y, y, x); > } > > it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. > cal...

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar" correctly, h...

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the