Re: How to implement pattens with more that 30 alternatives
On Wed, 2009-12-23 at 10:11 +0530, Mohamed Shafi wrote: 2009/12/22 Richard Earnshaw rearn...@arm.com: On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote: I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Or use the more modern iterators approach. Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the same pattern, whereas in this case we have a single insn that needs to accept many different operand combinartions? Yes, but that is often better, I suspect, than having too fancy a pattern that breaks the optimization simplifications that genrecog does. Note that the attributes that were requested could be made part of the iterator as well, using a mode_attribute. I can't find a back-end that does this. Can you show me a example? I think the mips port is currently the most comprehensive example for use of iterators. R.
Re: How to implement pattens with more that 30 alternatives
On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote: I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Or use the more modern iterators approach. Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the same pattern, whereas in this case we have a single insn that needs to accept many different operand combinartions? Yes, but that is often better, I suspect, than having too fancy a pattern that breaks the optimization simplifications that genrecog does. Note that the attributes that were requested could be made part of the iterator as well, using a mode_attribute. R.
Re: How to implement pattens with more that 30 alternatives
Or use the more modern iterators approach. Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the same pattern, whereas in this case we have a single insn that needs to accept many different operand combinartions? Yes, but that is often better, I suspect, than having too fancy a pattern that breaks the optimization simplifications that genrecog does. My understanding was that you should not have multiple patterns that match the same RTL. Especially with things like mov, it's important that all alternatives be the same insn so that register allocation and reload work. i.e. the following will work as expected: (define_insn *my_movsi (set (match_operand:SI ... =a,b) (match_operand:SI ... ab,ab))) However the following will not. Once gcc has picked a particular insn (_a or _b), it will tend to stick with it and not try other patterns. (define_insn *my_movsi_a (set (match_operand:SI ... =a) (match_operand:SI ... ab))) (define_insn *my_movsi_b (set (match_operand:SI ... =b) (match_operand:SI ... ab))) Paul
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote: i.e. the following will work as expected: (define_insn *my_movsi (set (match_operand:SI ... =a,b) (match_operand:SI ... ab,ab))) However the following will not. Once gcc has picked a particular insn (_a or _b), it will tend to stick with it and not try other patterns. This is my understanding too - but it's a real nuisance. Suppose you have two optional ISA extensions that have their own move instructions. For the sake of conversation I'll call them Alice and Bob... no, I'll call them TARGET_MAVERICK and TARGET_NEON. Now you need a minimum of three copies of the movmode pattern that are mostly the same. It'd be nice if there was a way to compose instruction patterns :-( -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On Tue, 2009-12-22 at 09:10 -0500, Daniel Jacobowitz wrote: On Tue, Dec 22, 2009 at 12:09:55PM +, Paul Brook wrote: i.e. the following will work as expected: (define_insn *my_movsi (set (match_operand:SI ... =a,b) (match_operand:SI ... ab,ab))) However the following will not. Once gcc has picked a particular insn (_a or _b), it will tend to stick with it and not try other patterns. This is my understanding too - but it's a real nuisance. Suppose you have two optional ISA extensions that have their own move instructions. For the sake of conversation I'll call them Alice and Bob... no, I'll call them TARGET_MAVERICK and TARGET_NEON. Now you need a minimum of three copies of the movmode pattern that are mostly the same. It'd be nice if there was a way to compose instruction patterns :-( There is. Look at attribute enabled. I've not worked out how to use that properly yet, but it is used in the m68k back-end. R.
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 02:12:48PM +, Richard Earnshaw wrote: There is. Look at attribute enabled. I've not worked out how to use that properly yet, but it is used in the m68k back-end. Interesting. This seems to replace needing either (A) a bunch of similar patterns with different insn predicates, or (B) a bunch of new constraints that expand to not available unless such and such ISA is enabled. That's a nice improvement, although we're back to the number of alternatives getting quite high. This does still leave us with weird operand predicates. For instance, in a patch I'm working on for ARM cmpdi patterns, I ended up needing cmpdi_lhs_operand and cmpdi_rhs_operand predicates because Cirrus and VFP targets accept different constants. Automatically generating that would be a bit excessive though. -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On 12/22/09, Daniel Jacobowitz d...@false.org wrote: in a patch I'm working on for ARM cmpdi patterns, I ended up needing cmpdi_lhs_operand and cmpdi_rhs_operand predicates because Cirrus and VFP targets accept different constants. Automatically generating that would be a bit excessive though. I wouldn't bother implementaing that if the VFP/Cirrus conflict is the only thing that needs that. GCC's has never been able to generate working code for Cirrus MaverickCrunch for over a dozen separate reasons, from incorrect use of the way the Maverick sets the condition codes to hardware bugs in the 64-bit instructions (or in the way GCC uses them). I eventually cooked up over a dozen patches to make 4.[23] generate reliable crunch floating point code but if you enable the 64-bit insns it still fails the openssl testsuite. M
Re: How to implement pattens with more that 30 alternatives
On Tue, Dec 22, 2009 at 04:24:01PM +, Martin Guy wrote: I wouldn't bother implementaing that if the VFP/Cirrus conflict is the only thing that needs that. GCC's has never been able to generate working code for Cirrus MaverickCrunch for over a dozen separate reasons, from incorrect use of the way the Maverick sets the condition codes to hardware bugs in the 64-bit instructions (or in the way GCC uses them). I eventually cooked up over a dozen patches to make 4.[23] generate reliable crunch floating point code but if you enable the 64-bit insns it still fails the openssl testsuite. Interesting, I knew you had a lot of Cirrus patches but I didn't realize the state of the checked-in code was so bad. Is what's there useful or actively harmful? -- Daniel Jacobowitz CodeSourcery
Re: How to implement pattens with more that 30 alternatives
On 12/22/09, Daniel Jacobowitz d...@false.org wrote: Interesting, I knew you had a lot of Cirrus patches but I didn't realize the state of the checked-in code was so bad. Is what's there useful or actively harmful? Neither useful nor harmful except in that it adds noise to the arm backend. It's useful if you want to get a working compiler by applying my patches... The basic insn description is ok but the algorithms to use the insns are defective; I suppose it's passively harmful since until it's fixed it just adds noise and size to the arm backend. I did the copyright assignment thing but I haven't mainlined the code, partly because it currently has an embarassing -mcirrus-di flag to enable the imperfect 64-bit int support, partly out of laziness (the dejagnu testsuite for all insns it can generate and for the more interesting resolved bugs). Maybe one day... M
Re: How to implement pattens with more that 30 alternatives
2009/12/22 Richard Earnshaw rearn...@arm.com: On Mon, 2009-12-21 at 18:44 +, Paul Brook wrote: I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Or use the more modern iterators approach. Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the same pattern, whereas in this case we have a single insn that needs to accept many different operand combinartions? Yes, but that is often better, I suspect, than having too fancy a pattern that breaks the optimization simplifications that genrecog does. Note that the attributes that were requested could be made part of the iterator as well, using a mode_attribute. I can't find a back-end that does this. Can you show me a example? Regards, Shafi
Re: How to implement pattens with more that 30 alternatives
On Monday 21 December 2009, Mohamed Shafi wrote: Hi all, I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Paul
Re: How to implement pattens with more that 30 alternatives
On Mon, 2009-12-21 at 16:06 +, Paul Brook wrote: On Monday 21 December 2009, Mohamed Shafi wrote: Hi all, I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Or use the more modern iterators approach. R.
Re: How to implement pattens with more that 30 alternatives
I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of scheduling framework i have to write the move patterns with more clarity, so that i could control the scheduling with the help of attributes. Re-writting the pattern resulted in movsi pattern with 41 alternatives :( Use rtl expressions instead of alternatives. e.g. arm.md:arith_shiftsi Or use the more modern iterators approach. Aren't iterators for generating multiple insns (e.g. movsi and movdi) from the same pattern, whereas in this case we have a single insn that needs to accept many different operand combinartions? Paul
