similar to: Change prototype for TargetInstrInfo::foldMemoryOperandImpl

Hi Quentin, I get following error from MachineVerifier: # End machine code for function f. *** Bad machine code: Missing mayLoad flag *** which comes from: // Check the MachineMemOperands for basic consistency. for (MachineMemOperand *Op : MI->memoperands()) { if (Op->isLoad() && !MI->mayLoad()) report("Missing mayLoad flag", MI); if (Op->isStore()

On Wed, 15 Apr 2020 at 03:36, John Brawn <John.Brawn at arm.com> wrote: > > > Could you please point out what am I doing wrong in the patch ? > > It's because you're getting the function name by doing > callee->getName().str().c_str() > The str() call generates a temporary copy of the name which ceases to exist outside of this expression > causing the

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, however in generated

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

On Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > > On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > >> >> On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: >> >>> Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't*

On May 17, 2011, at 2:10 PM, Justin Holewinski wrote: > I plan on eventually implementing both and seeing which works best for different types of input. > > If virtual registers are used, how do you disable final register allocation in the back-end? If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.

On Aug 18, 2010, at 11:31 AM, Jakob Stoklund Olesen wrote: > > On Aug 18, 2010, at 11:22 AM, Chris Lattner wrote: > >> >> On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: >> >>> >>> On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: >>> >>>> Some things to consider: When the input to the zext is spilled, the reload

On Tue, May 17, 2011 at 2:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > > > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: > >> What you can do instead is: > >> > >> 1) Just use virtual registers and skip register allocation, or > >> > >> 2) Allocate to a

I would expect that it shouldn't be too hard to pass around a reference to LiveIntervalAnalysis*. Patches welcome :) - Matthias > On Apr 27, 2016, at 11:38 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ping. > > Either this can be implemented easily, or the current SystemZ optimization LAY -> AGSI in foldMemoryOperandImpl() should be

Hi, Compiling attached test-case, which is reduced version of of uECC_shared_secret from tinycrypt library [1], with --target=arm-linux-gnueabi -march=armv6-m -Oz -S results in reloading of register holding function's address before every call to blx: ldr r3, .LCPI0_0 blx r3 mov r0, r6 mov r1, r5 mov r2, r4 ldr r3,

Hi, I wonder if it would be possible to extend foldMemoryOperandImp() so that targets can check for liveness of a particular phys reg? The case I am thinking of is when the new instruction clobbers the CC reg, while the old one did not. In this case the new instruction can only become a replacement if the CC reg is known to be dead. The idea is that liveness of phys regs should be available

On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: >> What you can do instead is: >> >> 1) Just use virtual registers and skip register allocation, or >> >> 2) Allocate to a small register file, implement memory operand folding, and pretend that spill slots are registers. >> >> /jakob >>

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't* folded into a load, what you're really looking for is a code placement pass which tries to put the zexts in non-redundant (and non-partially redundant) places. That

Hi, I wonder if live-in lists can be trusted to be accurate during register allocation / foldMemoryOperandImp(). On SystemZ, a compare register-register which has one of the registers spilled can fold that reload into a compare register-memory instruction. In order to do this also with the first (LHS) register, the operands must be swapped. This can only reasonably be done when all the CC

On Aug 18, 2010, at 11:13 AM, Jakob Stoklund Olesen wrote: > > On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > >> Some things to consider: When the input to the zext is spilled, the reload can be folded into the zext on almost all targets, making the zext free. When the zext *isn't* folded into a load, what you're really looking for is a code placement pass which

On Tue, 16 Jun 2020 at 15:47, Tim Northover <t.p.northover at gmail.com> wrote: > > On Tue, 16 Jun 2020 at 10:23, Prathamesh Kulkarni via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > (b) Modifies RegisterCoalescer::reMaterializeTrivialDef and > > TargetInstrInfo::isReallyTriviallyReMaterializableGeneric to check > > for single live def, instead of

Hi, For the following test-case: void foo(unsigned, unsigned); void f() { foo(10, 20); foo(10, 20); } clang --target=arm-linux-gnueabi -mthumb -O2 generates: push {r4, r5, r7, lr} movs r4, #10 movs r5, #20 movs r0, r4 movs r1, r5 bl foo movs r0, r4 movs r1, r5 bl foo pop {r4,

On Jul 15, 2012, at 9:20 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. > > 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other

I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:

I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when