Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On Wednesday 19 October 2016 07:51 PM, Georg-Johann Lay wrote: On 17.10.2016 09:27, Pitchumani Sivanupandi wrote: On Thursday 13 October 2016 08:42 PM, Georg-Johann Lay wrote: On 13.10.2016 13:44, Pitchumani Sivanupandi wrote: On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote: On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Yes. I tried to split 'casesi' into several based on case values so that compare is done in less expensive modes (i.e. QI or HI). In few cases it is not possible without SImode subtract/ compare. Pattern casesi will have index in SI mode. So, out of range checks will be expensive as most common uses (in AVR) of case values will be in QI/HI mode. e.g. if case values in QI range if upper three bytes index is set goto out_of_range offset = index - lower_bound (QImode) if offset > case_range (QImode) goto out_of_range goto jump_table + offset else if case values in HI range if index[2,3] is set goto out_of_range offset = index - lower_bound (HImode) if offset > case_range (HImode) goto out_of_range goto jump_table + offset This modification will not work for the negative index values. Because code to check upper bytes of index will be expensive than the SImode subtract/ compare. So, I'm trying to update fix to have SImode subtract/ compare if the case values include negative integers. For, others will try to optimize as mentioned above. Is that approach OK? But the above code will be executed at run time and add even more overhead, or am I missing something? If you conclude statically at expand time from the case ranges then we might hit a similar problem as with the original subreg computation. No. Lower bound and case range are const_int_operand, known at compile time. Yes, but if the range if form 10 to 90, say, then you still don't know whether HImode and QImode is appropriate or not which adds to code size and register pressure. As I mentioned earlier, I am working on a different approach which would revert your changes: The casesi is basically unaltered (except for operand clean-ups and avoidance of clobbering subregs). The ups of my approach are: * The original value is known and whether is is QI or HI. * The signedness is known which allows to use the maximum range of QI resp. HI depending on the sign. * Also works on negative values. * All is done at compile time, no need for extra code. * No intermediate 32-bit values, no unnecessary increase of reg pressure. * Optimization can be switched off by -fdisable if desired. * Result can be seen in dumps. The downsides are: * Also needs some lines of code (~400). * Makes assumptions on the anatomy of the code, i.e. extension precedes casesi. First we should decide which route to follow as the changes are conflicting each other. I have not so much time to work on the stuff but the results are promising. If you are interested in the changes, I can supply it but it's all still work in progress. Ok. I'll put this patch on hold for now. Please share if you have draft version of your fix is ready. Thanks. Regards, Pitchumani
Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On 17.10.2016 09:27, Pitchumani Sivanupandi wrote: On Thursday 13 October 2016 08:42 PM, Georg-Johann Lay wrote: On 13.10.2016 13:44, Pitchumani Sivanupandi wrote: On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote: On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Yes. I tried to split 'casesi' into several based on case values so that compare is done in less expensive modes (i.e. QI or HI). In few cases it is not possible without SImode subtract/ compare. Pattern casesi will have index in SI mode. So, out of range checks will be expensive as most common uses (in AVR) of case values will be in QI/HI mode. e.g. if case values in QI range if upper three bytes index is set goto out_of_range offset = index - lower_bound (QImode) if offset > case_range (QImode) goto out_of_range goto jump_table + offset else if case values in HI range if index[2,3] is set goto out_of_range offset = index - lower_bound (HImode) if offset > case_range (HImode) goto out_of_range goto jump_table + offset This modification will not work for the negative index values. Because code to check upper bytes of index will be expensive than the SImode subtract/ compare. So, I'm trying to update fix to have SImode subtract/ compare if the case values include negative integers. For, others will try to optimize as mentioned above. Is that approach OK? But the above code will be executed at run time and add even more overhead, or am I missing something? If you conclude statically at expand time from the case ranges then we might hit a similar problem as with the original subreg computation. No. Lower bound and case range are const_int_operand, known at compile time. Yes, but if the range if form 10 to 90, say, then you still don't know whether HImode and QImode is appropriate or not which adds to code size and register pressure. As I mentioned earlier, I am working on a different approach which would revert your changes: The casesi is basically unaltered (except for operand clean-ups and avoidance of clobbering subregs). The ups of my approach are: * The original value is known and whether is is QI or HI. * The signedness is known which allows to use the maximum range of QI resp. HI depending on the sign. * Also works on negative values. * All is done at compile time, no need for extra code. * No intermediate 32-bit values, no unnecessary increase of reg pressure. * Optimization can be switched off by -fdisable if desired. * Result can be seen in dumps. The downsides are: * Also needs some lines of code (~400). * Makes assumptions on the anatomy of the code, i.e. extension precedes casesi. First we should decide which route to follow as the changes are conflicting each other. I have not so much time to work on the stuff but the results are promising. If you are interested in the changes, I can supply it but it's all still work in progress. Johann Tried to optimize code generated based on case values range. Attached the revised patch. Tested with avrtest, no regression found. Is it OK? Unfortunately, the generated code (setting cc0, a reg and pc) cannot be wrapped into an unspec or parallel and then later be rectified... I am thinking about a new avr target pass to tidy up the code if no 32-bit computation is needed, but this will be some effort. Ok. Regards, Pitchumani gcc/ChangeLog 2016-10-17 Pitchumani SivanupandiPR target/71676 PR target/71678 * config/avr/avr.md (casesi_index_qi, casesi_index_hi, casesi_index_si): Add new expands, called by casesi based on case values range. gcc/testsuite/ChangeLog 2016-10-17 Pitchumani Sivanupandi PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test.
Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On Thursday 13 October 2016 08:42 PM, Georg-Johann Lay wrote: On 13.10.2016 13:44, Pitchumani Sivanupandi wrote: On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote: On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Yes. I tried to split 'casesi' into several based on case values so that compare is done in less expensive modes (i.e. QI or HI). In few cases it is not possible without SImode subtract/ compare. Pattern casesi will have index in SI mode. So, out of range checks will be expensive as most common uses (in AVR) of case values will be in QI/HI mode. e.g. if case values in QI range if upper three bytes index is set goto out_of_range offset = index - lower_bound (QImode) if offset > case_range (QImode) goto out_of_range goto jump_table + offset else if case values in HI range if index[2,3] is set goto out_of_range offset = index - lower_bound (HImode) if offset > case_range (HImode) goto out_of_range goto jump_table + offset This modification will not work for the negative index values. Because code to check upper bytes of index will be expensive than the SImode subtract/ compare. So, I'm trying to update fix to have SImode subtract/ compare if the case values include negative integers. For, others will try to optimize as mentioned above. Is that approach OK? But the above code will be executed at run time and add even more overhead, or am I missing something? If you conclude statically at expand time from the case ranges then we might hit a similar problem as with the original subreg computation. No. Lower bound and case range are const_int_operand, known at compile time. Tried to optimize code generated based on case values range. Attached the revised patch. Tested with avrtest, no regression found. Is it OK? Unfortunately, the generated code (setting cc0, a reg and pc) cannot be wrapped into an unspec or parallel and then later be rectified... I am thinking about a new avr target pass to tidy up the code if no 32-bit computation is needed, but this will be some effort. Ok. Regards, Pitchumani gcc/ChangeLog 2016-10-17 Pitchumani SivanupandiPR target/71676 PR target/71678 * config/avr/avr.md (casesi_index_qi, casesi_index_hi, casesi_index_si): Add new expands, called by casesi based on case values range. gcc/testsuite/ChangeLog 2016-10-17 Pitchumani Sivanupandi PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test. diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md index 97f3561..b58db14 100644 --- a/gcc/config/avr/avr.md +++ b/gcc/config/avr/avr.md @@ -5152,16 +5152,95 @@ (set_attr "isa" "eijmp") (set_attr "cc" "clobber")]) +; casesi for QI mode case values +(define_expand "casesi_index_qi" + [(set (cc0) +(compare:QI (subreg:QI (match_dup 0) 0) +(match_operand 2 "const_int_operand" ""))) -(define_expand "casesi" - [(parallel [(set (match_dup 6) - (minus:HI (subreg:HI (match_operand:SI 0 "register_operand" "") 0) - (match_operand:HI 1 "register_operand" ""))) - (clobber (scratch:QI))]) - (parallel [(set (cc0) - (compare (match_dup 6) -(match_operand:HI 2 "register_operand" ""))) - (clobber (match_scratch:QI 9 ""))]) + (set (pc) +(if_then_else (gtu (cc0) + (const_int 0)) + (label_ref (match_operand 4 "" "")) + (pc))) + + (set (match_dup 9) +(match_dup 7)) + + (parallel [(set (pc) + (unspec:HI [(match_dup 9)] UNSPEC_INDEX_JMP)) + (use (label_ref (match_operand 3 "" ""))) + (clobber (match_dup 9)) + (clobber (match_dup 8))])] + "" + { +operands[5] = gen_reg_rtx
Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On 13.10.2016 13:44, Pitchumani Sivanupandi wrote: On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote: On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Yes. I tried to split 'casesi' into several based on case values so that compare is done in less expensive modes (i.e. QI or HI). In few cases it is not possible without SImode subtract/ compare. Pattern casesi will have index in SI mode. So, out of range checks will be expensive as most common uses (in AVR) of case values will be in QI/HI mode. e.g. if case values in QI range if upper three bytes index is set goto out_of_range offset = index - lower_bound (QImode) if offset > case_range (QImode) goto out_of_range goto jump_table + offset else if case values in HI range if index[2,3] is set goto out_of_range offset = index - lower_bound (HImode) if offset > case_range (HImode) goto out_of_range goto jump_table + offset This modification will not work for the negative index values. Because code to check upper bytes of index will be expensive than the SImode subtract/ compare. So, I'm trying to update fix to have SImode subtract/ compare if the case values include negative integers. For, others will try to optimize as mentioned above. Is that approach OK? But the above code will be executed at run time and add even more overhead, or am I missing something? If you conclude statically at expand time from the case ranges then we might hit a similar problem as with the original subreg computation. Unfortunately, the generated code (setting cc0, a reg and pc) cannot be wrapped into an unspec or parallel and then later be rectified... I am thinking about a new avr target pass to tidy up the code if no 32-bit computation is needed, but this will be some effort. Johann Alternatively we can have flags to generate shorter code for 'casesi' using HImode subtract/ compare. But correctness is not guaranteed (PR71676). Regards, Pitchumani
Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote: On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Yes. I tried to split 'casesi' into several based on case values so that compare is done in less expensive modes (i.e. QI or HI). In few cases it is not possible without SImode subtract/ compare. Pattern casesi will have index in SI mode. So, out of range checks will be expensive as most common uses (in AVR) of case values will be in QI/HI mode. e.g. if case values in QI range if upper three bytes index is set goto out_of_range offset = index - lower_bound (QImode) if offset > case_range (QImode) goto out_of_range goto jump_table + offset else if case values in HI range if index[2,3] is set goto out_of_range offset = index - lower_bound (HImode) if offset > case_range (HImode) goto out_of_range goto jump_table + offset This modification will not work for the negative index values. Because code to check upper bytes of index will be expensive than the SImode subtract/ compare. So, I'm trying to update fix to have SImode subtract/ compare if the case values include negative integers. For, others will try to optimize as mentioned above. Is that approach OK? Alternatively we can have flags to generate shorter code for 'casesi' using HImode subtract/ compare. But correctness is not guaranteed (PR71676). Regards, Pitchumani
Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand
On 26.09.2016 15:19, Pitchumani Sivanupandi wrote: Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. But this means that all comparisons are now performed in SImode which is a great performance loss for most programs which will switch on 16-bit values. IMO we need a less intrusive (w.r.t. performance) approach. Johann Regtested using avrtest. No regression found. If OK, could someone commit please? Is this OK for gcc-5-branch? Regards, Pitchumani gcc/ChangeLog 2016-09-26 Pitchumani SivanupandiPR target/71676 PR target/71678 * config/avr/avr.md (casesi): Change index compare to SI mode. gcc/testsuite/ChangeLog 2016-09-26 Pitchumani Sivanupandi PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test.
[patch, avr, pr71676 and pr71678] Issues with casesi expand
Attached patch for PR71676 and PR71678. PR71676 is for AVR target that generates wrong code when switch case index is more than 16 bits. Switch case index of larger than SImode are checked for out of range before 'casesi' expand. RTL expand of casesi gets index as SImode, but index is compared in HImode and ignores upper 16bits. Attached patch changes the expansion for casesi to make the index comparison in SImode and code generation accordingly. PR71678 is ICE because below pattern in 'casesi' is not recognized. (set (reg:HI 47) (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0) (reg:HI 45))) Fix of PR71676 avoids the above pattern as it changes the comparison to SImode. Regtested using avrtest. No regression found. If OK, could someone commit please? Is this OK for gcc-5-branch? Regards, Pitchumani gcc/ChangeLog 2016-09-26 Pitchumani SivanupandiPR target/71676 PR target/71678 * config/avr/avr.md (casesi): Change index compare to SI mode. gcc/testsuite/ChangeLog 2016-09-26 Pitchumani Sivanupandi PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test. diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md index 97f3561..4b1bf9c 100644 --- a/gcc/config/avr/avr.md +++ b/gcc/config/avr/avr.md @@ -5155,12 +5155,12 @@ (define_expand "casesi" [(parallel [(set (match_dup 6) - (minus:HI (subreg:HI (match_operand:SI 0 "register_operand" "") 0) - (match_operand:HI 1 "register_operand" ""))) + (minus:SI (match_operand:SI 0 "register_operand" "") + (match_operand:SI 1 "register_operand" ""))) (clobber (scratch:QI))]) (parallel [(set (cc0) (compare (match_dup 6) -(match_operand:HI 2 "register_operand" ""))) +(match_operand:SI 2 "register_operand" ""))) (clobber (match_scratch:QI 9 ""))]) (set (pc) @@ -5179,20 +5179,20 @@ (clobber (match_dup 8))])] "" { -operands[6] = gen_reg_rtx (HImode); +operands[6] = gen_reg_rtx (SImode); if (AVR_HAVE_EIJMP_EICALL) { -operands[7] = operands[6]; +operands[7] = simplify_gen_subreg (HImode, operands[6], SImode, 0); operands[8] = all_regs_rtx[24]; operands[10] = gen_rtx_REG (HImode, REG_Z); } else { -operands[7] = gen_rtx_PLUS (HImode, operands[6], +operands[7] = gen_rtx_PLUS (HImode, simplify_gen_subreg (HImode, operands[6], SImode, 0), gen_rtx_LABEL_REF (VOIDmode, operands[3])); operands[8] = const0_rtx; -operands[10] = operands[6]; +operands[10] = simplify_gen_subreg (HImode, operands[6], SImode, 0); } }) diff --git a/gcc/testsuite/gcc.target/avr/pr71676-1.c b/gcc/testsuite/gcc.target/avr/pr71676-1.c new file mode 100644 index 000..9a74909 --- /dev/null +++ b/gcc/testsuite/gcc.target/avr/pr71676-1.c @@ -0,0 +1,332 @@ +/* { dg-do run } */ +/* { dg-options "-Os -Wno-overflow" } */ + +#include "exit-abort.h" +volatile unsigned char y; + +unsigned char __attribute__((noinline)) foo1 (char x) +{ +switch (x) +{ + case (char)0x11: y = 7; break; + case (char)0x12: y = 4; break; + case (char)0x13: y = 8; break; + case (char)0x14: y = 21; break; + case (char)0x15: y = 65; break; + case (char)0x16: y = 27; break; + case (char)0x17: y = 72; break; + case (char)0x18: y = 39; break; + default: y=0; +} +return y; +} + +unsigned char __attribute__((noinline)) foo2 (char x) +{ +switch (x) +{ + case 0x01: y = 7; break; + case 0x02: y = 4; break; + case 0x03: y = 8; break; + case 0x04: y = 21; break; + case 0x05: y = 65; break; + case 0x06: y = 27; break; + case 0x07: y = 72; break; + case 0x08: y = 39; break; + default: y=0; +} +return y; +} + +unsigned char __attribute__((noinline)) foo3 (char x) +{ +switch (x) +{ + case 0x101L: y = 7; break; + case 0x102L: y = 4; break; + case 0x103L: y = 8; break; + case 0x104L: y = 21; break; + case 0x105L: y = 65; break; + case 0x106L: y = 27; break; + case 0x107L: y = 72; break; + case 0x108L: y = 39; break; + default: y=0; +} +return y; +} + +unsigned char __attribute__((noinline)) foo4 (char x) +{ +switch (x) +{ + case 0x10001LL: y = 7; break; + case 0x10002LL: y = 4; break; + case 0x10003LL: y = 8; break; + case 0x10004LL: y = 21; break; + case 0x10005LL: y = 65; break; + case 0x10006LL: y = 27; break; + case 0x10007LL: y = 72; break; + case 0x10008LL: y =