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
Hi,
I'm trying to enable the pre-decrementing and post-incrementing based
addressing modes for my target. So far without any success :(
I enabled these modes in my TargetLowering class using
setIndexedLoadAction and setIndexedStoreAction calls. I also defined
getPreIndexedAddressParts and getPostIndexedAddressParts. And I can see
that DAGCombiner::CombineToPostIndexedLoadStore is invoked. But this
function never does any replacements and very seldomly invoke
getPostIndexedAddressParts and so on, even in those situations where I
would assume it.
For example, it does not use these modes for the code like:
void test_postinc(int array[], int i)
{
array[i] = 1;
array[i+1] = 1;
array[i+2] = 1;
array[i+3] = 1;
}
So, I'm wondering how good is the support for these modes in LLVM? Do I
miss something which should be implemented for my target to enable it?
It looks like only PowerPC backend tries to make use of it, but even
there it is not implemented completely.
And, BTW, are there any good test-cases or sample code (either ll or c
files) that is (or should be) translated by LLVM using these modes? I'd
like to get a better understanding about the situations where it can
happen at all. For example, is the code like above a good candidate for
it or not?
-Roman
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
> > I enabled these modes in my TargetLowering class using > setIndexedLoadAction and setIndexedStoreAction calls. I also defined > getPreIndexedAddressParts and getPostIndexedAddressParts. And I can > see > that DAGCombiner::CombineToPostIndexedLoadStore is invoked. But this > function never does any replacements and very seldomly invoke > getPostIndexedAddressParts and so on, even in those situations where I > would assume it.Ok,> > For example, it does not use these modes for the code like: > void test_postinc(int array[], int i) > { > array[i] = 1; > array[i+1] = 1; > array[i+2] = 1; > array[i+3] = 1; > }See below.> > So, I'm wondering how good is the support for these modes in LLVM? > Do I > miss something which should be implemented for my target to enable it? > It looks like only PowerPC backend tries to make use of it, but even > there it is not implemented completely. > > And, BTW, are there any good test-cases or sample code (either ll or c > files) that is (or should be) translated by LLVM using these modes? > I'd > like to get a better understanding about the situations where it can > happen at all. For example, is the code like above a good candidate > for > it or not?Indexed load / store supports is not "done". Currently only PPC target makes use of it. Lots of testing and further refinement is needed. Basically, the only cases where transformation will happen now is if the load/store address has other non-address uses. e.g. x1 = load [base] x2 = base + 4 As for your example, let's first example why array[i+1] = 1; array[i +2] = 1; does not currently triggers a transformation: array[i+1] = 1 array[i+2] = 1 => tmp = array * 4 base = tmp + i store 1, [base + 4] store 1, [base + 8] Unfortunately base+8 is not written as (base+4)+4 so the transformation does not happen. We need to add DAG combiner transformation to make that happen. If you are interested in making that happen, we would be happen to help. :-) The reason that array[i] = 1; array[i+1] = 1; doesn't trigger a post- inc transformation is different. In theory, this should be array[i] = 1 array[i+1] = 1 => tmp = array * 4 base = array * 4 + i store 1, [base] store 1, [base + 4] The first store should have been transformed into a post-inc store. The issue is in SDNode CSE. If you take a look at pre-legalizer DAG dump. You will see this: tmp = array * 4 base1 = array * 4 + i base2 = i + array * 4 store 1, [base1] store 2, [base2 + 4] So the post-inc transformation does not recognize an opportunity. The current "fix" should be to teach SDNode CSE to understand commutative property to eliminate one of the add operation. Chris can say more about the issues related. Hope this helps. Evan> > -Roman > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi, I just updated my LLVM sources from CVS/HEAD and rebuilt them. And I downloaded the GCC4 frontend from the 1.9 release. Now I cannot compile anything, since GCC frontend seems to produce BC files that cannot be read by llvm-dis, llc and other utils. llvm-dis shows a following message: Bytecode formats < 7 are not longer supported. Use llvm-upgrade. (Vers=6, Pos=9) But since the new llvm-dis cannot disassemble, I cannot use llvm-upgrade, since I need a way to produce an *.ll file. What's wrong? I thought that LLVM 1.9 GCC4 frontend produces BC files in a new format already? Or do I need to rebuild the front-end from the CVS? May be there are pre-built images available? -Roman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com