llvm dev - Nov 2006 - [LLVMdev] FP emulation (continued)

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