similar to: [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)

On Jun 3, 2009, at 5:51 PM, Evan Cheng wrote: > I vote for execution of SimpleRewriter. Yeah, go ahead and axe it: Off with its head! -Chris > > > Evan > > On Jun 3, 2009, at 1:34 PM, Lang Hames wrote: > >> Hi all, >> >> Is anyone still using SimpleRewriter (formerly known as >> SimpleSpiller)? A quick check with the test suite suggests that it's

I vote for execution of SimpleRewriter. Evan On Jun 3, 2009, at 1:34 PM, Lang Hames wrote: > Hi all, > > Is anyone still using SimpleRewriter (formerly known as > SimpleSpiller)? A quick check with the test suite suggests that it's > badly broken. If it's not being used I'd like to remove it as part of > my tidy-up of the register allocator. > > - Lang. >

R.I.P. SimpleRewriter. If anyone needs it resurrected let me know. This leaves LocalRewriter (the default) and the new TrivialRewriter, which is for use only with the new in-place spilling framework. This framework appears (if you squint just right) to be basically functional now, but it produces awful code. If you want to play with it you can invoke it with the magical combination of

On Thursday 04 June 2009 13:57, Lang Hames wrote: > R.I.P. SimpleRewriter. If anyone needs it resurrected let me know. > > This leaves LocalRewriter (the default) and the new TrivialRewriter, > which is for use only with the new in-place spilling framework. This > framework appears (if you squint just right) to be basically > functional now, but it produces awful code. If you

The new spilling framework inserts spill code in-place (during register allocation) rather than deferring it using VirtRegMap/VirtRegRewriter. The goal is to enable techniques like iterative splitting to be implemented. It should also be a bit tidier as it keeps more state in the MachineFunction, rather than in book-keeping structures like VirtRegMap. The work is in the very early stages though.

On Thursday 04 June 2009 19:03, Lang Hames wrote: > The new spilling framework inserts spill code in-place (during > register allocation) rather than deferring it using > VirtRegMap/VirtRegRewriter. The goal is to enable techniques like > iterative splitting to be implemented. It should also be a bit tidier > as it keeps more state in the MachineFunction, rather than in >

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

On May 27, 2008, at 5:36 PM, David Greene wrote: > I've been playing around with spillers and found that the > SimpleSpiller fails > badly on a particular code. > > The problem arises because SimpleSpiller does the test > VRM.isAssignedReg(virtReg) which is implemented as: > > 00183 bool isAssignedReg(unsigned virtReg) const { > 00184 if

Thanks Jakob. I should have mentioned that earlier. :) When you see mismatched sizes on operands it's a fair bet that the subreg rewriting has gone wrong. I should have pulled that entirely out of the preg search loop in the previous example. Fixed version attached. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Susan, Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg operand, taking the subregister index into account. That is what my examples have been doing manually. Using substPhysReg would allow you to tidy the Gcra code up slightly. - Lang. On Thu, Nov 15, 2012 at 11:21 AM, Lang

Thanks Lang, I'll try substPhysReg. I did try your latest code, and although it made the assembler errors go away, now some of my tests produce bad output when executed. I need to look into that some more... (I did change my "usedPregSet" to be ALL pregs used in the whole function, not just those in the current instruction, so the problem should not be the erroneous

On Friday 30 May 2008 15:13, Evan Cheng wrote: > No, every vr is assigned a physical register. It needs to know how > what physical register to reload it, for example. Looks like > SimpleSpiller has bit-rotted. There really isn't a good reason to fix > it. Unless you want to use it, I'll just remove it. No, don't remove it! It's a valuable debugging tool. I've

Hi Again, I'm a little confused regarding what is the exact Orc's functions I should use in order to save the functions code in a code cache so it could be later replaced with different versions of it and I appreciate your help. Just a reminder I want to dynamically recompile the program based on profile collected at the run-time. I would like to start executing the program from the

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Hi All, The initializer patch review at https://reviews.llvm.org/D74300 has been updated. The new version contains a MachOPlatform implementation that demonstrates how Platforms and ObjectLinkingLayer::Plugins can work together to implement platform specific initialization. In this case, the MachOPlatform installs a plugin that scans objects for __objc_classlist and __objc_selref sections and

Hi All, No open source work to speak of this week. All my effort is going on tidying up the new initializers patch which I expect to land this weekend, or early next week. -- Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200131/db360b1d/attachment.html>

Hi all, I'd like to kill off the bigblock register allocator. Is anyone still using it? Cheers, Lang.

Hi Geoff, We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work > for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at

Oooh. Neat. Thanks Dave. Please go ahead and commit that. Arnaud - I have no idea whether Dave's patch will help with this bug, but it's certainly worth testing. - Lang. On Wed, Sep 10, 2014 at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > While I'm not sure where the leak is, using some pre-canned memory > management might help... > > Attached is a

Hi Sachin, llvm-dev, I've just committed a new PBQP solver which, among other things, should take care of this bug. Please let me know how it works out for you. Cheers, Lang. On Tue, Dec 15, 2009 at 5:54 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Sachin, > > Yes. Bernhard Scholz and I have just discussed a fix for this. I hope to > commit it in the next few days. I