search for: fake_us

...9;this' pointer at the end of the function, compelling the rest of the compiler to not optimize it away. At the moment there doesn't seem to be a good way to create such a fake use in LLVM (please enlighten us if you know of one), so we are proposing to introduce a new intrinsic (e.g. llvm.fake_use), which would take a single value argument, representing a use of that value. The intrinsic would be lowered to a new invariant TargetOpcode (e.g. FAKE_USE), which serves the same purpose at the MI level. Code emission would simply ignore the new opcode. Frontends could use the intrinsic to exten...

...that would mean that even small member functions would acquire a stack frame (on architectures where leaf routines can get away without one), which may degrade performance considerably. You could apply some heuristics and determine when a store is unnecessary, but inlining may complicate things. A fake_use operation would be inlined like any other instruction. We performed some internal evaluations of location coverage (at -O1 on x86), and about half of the member functions already had 100% location coverage for the this pointer, mostly because they are small. For these methods extending the live r...

Oops, forgot to reply-all (& adding a few other people to the 'to' line) ---------- Forwarded message ---------- From: David Blaikie <dblaikie at gmail.com> Date: Mon, Sep 21, 2015 at 11:22 AM Subject: Re: [llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode To: "Pieb, Wolfgang" <Wolfgang_Pieb at playstation.sony.com> On Mon, Sep 21, 2015 at 11:16 AM, Pieb, Wolfgang via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello! > > > > At Sony we've seen some serious customer interest in having the '...

I have code along the lines of: void foo(struct A *a) { struct B *b = a->m_B; /* do a whole bunch of things with b */ } When LLVM generates code for this, it sees that after initializing b, a is no longer used, so it is optimized out. Unfortunately, for debug, I'd like the value for a to be kept around, if only so that I can determine the value of b and go from there. I

> On Oct 31, 2014, at 5:28 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Kevin, > > Thank you for starting this discussion! Yes, sorry for being unresponsive for a few days. Sanjoy summarized the issues perfectly. > I think the distinction is really between whether the live values are > "live on call" or "live on return".