Hi,>> have not found any easy way to do it yet. For post-RA pass it is >> very easy and supported, but for pre-RA or post-code-selection - it >> is non obvious. > > I suggest a third approach:[snip]> 3. Write a machine function pass that runs before the RA that > translates these instructions into libcalls or other integer ops. > This would lower the f64 pseudo regs into 2x i32 pseudo regs. The > real RA should never see the bogus f64 regs.Thanks, this is a good idea. But I cannot figure out how to make a machine function pass run _BEFORE_ the RA. I guess I'm missing something very obvious. How do I enforce that a certain machine function pass runs before RA (LLVM Linear Scan RA in my case)??? I tried to add the RA pass as a requirement in the getAnalysisUsage() of my machine function pass, but this does not work, since RA is not registered as a usual pass and uses a special RA registry instead. Should my machine function pass be explicitly added to the getAnalysisUsage() of the Linear Scan RA pass? This would work probably, but it is not too nice, since it would change the existing LLVM pass in a target-specific way. And BTW, it seems to me that currently new RA passes are not allowed to derive from the existing ones. If it is correct, why so? Wouldn't it be nice? -Roman ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
On Wed, 29 Nov 2006, Roman Levenstein wrote:> Thanks, this is a good idea. > > But I cannot figure out how to make a machine function pass run > _BEFORE_ the RA. I guess I'm missing something very obvious.In your target's TargetMachine::addInstSelector method, add it to the pass mgr right after your isel.> And BTW, it seems to me that currently new RA passes are not allowed > to derive from the existing ones. If it is correct, why so? Wouldn't it > be nice?I'm not sure what you mean. We don't expose linscan through a public header, but a pass in the same .cpp file could subclass it. We haven't had a need to do this yet, so we don't have the provisions to do it. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Hi Chris, --- Chris Lattner <sabre at nondot.org> wrote:> On Wed, 29 Nov 2006, Roman Levenstein wrote: > > Thanks, this is a good idea. > > > > But I cannot figure out how to make a machine function pass run > > _BEFORE_ the RA. I guess I'm missing something very obvious. > > In your target's TargetMachine::addInstSelector method, add it to the > pass mgr right after your isel.Thanks a lot! This is exactly what I could not understand.>> And BTW, it seems to me that currently new RA passes are not >> allowed to derive from the existing ones. If it is correct, why so? >> Wouldn't it be nice? > > I'm not sure what you mean. We don't expose linscan through a public> header, but a pass in the same .cpp file could subclass it.> We haven't had a need to do this yet, so we don't have the provisions> to do it.OK, I see. I just had the idea that it could be useful, if someone defines a target-specific RA, which is a slight modification of an existing one, like the linear scan RA. Let's say it just executes some target-specific actions before and after the existing register allocator. Then you probably don't want to put these target-specific bits into the same file as the existing allocator. It would be much cleaner to define in a separate source file a new RA that in some sense "derives" from the existing RA (either using inheritance or by having a class member that is of a known existing RA class). Such a new RA would do some pre/post RA actions in its runOnMachineFunction() method and delegate a real RA job to the "parent" register allocator. Thanks again for your hint, -Roman ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com