Re: [patch RFC,PR50038]
Ping. Could please someone check if my approach is OK and it is worth to continue work on patch for PR50038? Thanks Ilya 2011/10/11 Ilya Enkovich enkovich@gmail.com: 2011/10/4 Richard Henderson r...@redhat.com: On 10/04/2011 08:42 AM, Joseph S. Myers wrote: On Tue, 4 Oct 2011, Ilya Tocar wrote: Hi everyone, This patch fixes PR 50038 (redundant zero extensions) by modifying implicit-zee pass to also remove unneeded zero extensions from QImode to SImode. Hardcoding particular modes like this in the target-independent parts of the compiler is fundamentally ill-conceived. Right now it hardcodes the (SImode, DImode) pair. You're adding hardcoding of (QImode, SImode) as well. But really it should consider all pairs of (integer mode, wider integer mode), with the machine description (or target hooks) determining which pairs are relevant on a particular target. Changing it not to hardcode particular modes would be better than adding a second pair. That along with not hard-coding ZERO_EXTEND. Both MIPS and Alpha have much the same free operations, but with SIGN_EXTEND. I remember rejecting one iteration of this pass with this hard-coded, but the pass was apparently approved by someone else without that being corrected. r~ Hello guys, Could you please look at my patch version? I tried to remove all unnecessary mode restrictions and cover SIGN_EXTEND case. I did not test this patch yet, just checked it worked on reproducer from PR50038. Thanks Ilya --- gcc/ * implicit-zee.c (ext_cand): New. (ext_cand_pool): Likewise. (add_ext_candidate): Likewise. (zee_init): Likewise. (zee_cleanup): Likewise. (combine_set_zero_extend): Get extend candidate as new parameter. Now handle sign extend cases and all modes. (transform_ifelse): Likewise. (merge_def_and_ze): Likewise. (combine_reaching_defs): Change parameter type. (zero_extend_info): Changed insn_list type. (add_removable_zero_extend): Relaxed mode and code filter. (find_removable_zero_extends): Changed return type. (find_and_remove_ze): Var type changes. (rest_of_handle_zee): Initialization and cleanup added.
Re: [patch RFC,PR50038]
2011/10/4 Richard Henderson r...@redhat.com: On 10/04/2011 08:42 AM, Joseph S. Myers wrote: On Tue, 4 Oct 2011, Ilya Tocar wrote: Hi everyone, This patch fixes PR 50038 (redundant zero extensions) by modifying implicit-zee pass to also remove unneeded zero extensions from QImode to SImode. Hardcoding particular modes like this in the target-independent parts of the compiler is fundamentally ill-conceived. Right now it hardcodes the (SImode, DImode) pair. You're adding hardcoding of (QImode, SImode) as well. But really it should consider all pairs of (integer mode, wider integer mode), with the machine description (or target hooks) determining which pairs are relevant on a particular target. Changing it not to hardcode particular modes would be better than adding a second pair. That along with not hard-coding ZERO_EXTEND. Both MIPS and Alpha have much the same free operations, but with SIGN_EXTEND. I remember rejecting one iteration of this pass with this hard-coded, but the pass was apparently approved by someone else without that being corrected. r~ Hello guys, Could you please look at my patch version? I tried to remove all unnecessary mode restrictions and cover SIGN_EXTEND case. I did not test this patch yet, just checked it worked on reproducer from PR50038. Thanks Ilya --- gcc/ * implicit-zee.c (ext_cand): New. (ext_cand_pool): Likewise. (add_ext_candidate): Likewise. (zee_init): Likewise. (zee_cleanup): Likewise. (combine_set_zero_extend): Get extend candidate as new parameter. Now handle sign extend cases and all modes. (transform_ifelse): Likewise. (merge_def_and_ze): Likewise. (combine_reaching_defs): Change parameter type. (zero_extend_info): Changed insn_list type. (add_removable_zero_extend): Relaxed mode and code filter. (find_removable_zero_extends): Changed return type. (find_and_remove_ze): Var type changes. (rest_of_handle_zee): Initialization and cleanup added. PR50038.diff Description: Binary data
[patch RFC,PR50038]
Hi everyone, This patch fixes PR 50038 (redundant zero extensions) by modifying implicit-zee pass to also remove unneeded zero extensions from QImode to SImode. There is 6% improvement in rgbyiqv test from EEMBC 2.0 benchmark on x86-64. I am not sure if this is correct approach ( tom modify implicit-zee pass), so comments are welcome. Also if this aproach is correct we will need to enable implicit-zee pass on some new targets ( for example x86 32bit). It passes bootstrap and make-check. Here is a Changelog: 2011-09-27 Ilya Tocar ilya.to...@intel.com * implicit-zee.c: Added 2011 to copyright. (combine_set_zero_extend): Add QImode. (merge_def_and_ze): Likewise. (add_removable_zero_extend): Likewise. (not_qi_to_si): New. (make_defs_and_copies_lists): Add check for QImode. zee.patch Description: Binary data
Re: [patch RFC,PR50038]
On Tue, 4 Oct 2011, Ilya Tocar wrote: Hi everyone, This patch fixes PR 50038 (redundant zero extensions) by modifying implicit-zee pass to also remove unneeded zero extensions from QImode to SImode. Hardcoding particular modes like this in the target-independent parts of the compiler is fundamentally ill-conceived. Right now it hardcodes the (SImode, DImode) pair. You're adding hardcoding of (QImode, SImode) as well. But really it should consider all pairs of (integer mode, wider integer mode), with the machine description (or target hooks) determining which pairs are relevant on a particular target. Changing it not to hardcode particular modes would be better than adding a second pair. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch RFC,PR50038]
On 10/04/2011 08:42 AM, Joseph S. Myers wrote: On Tue, 4 Oct 2011, Ilya Tocar wrote: Hi everyone, This patch fixes PR 50038 (redundant zero extensions) by modifying implicit-zee pass to also remove unneeded zero extensions from QImode to SImode. Hardcoding particular modes like this in the target-independent parts of the compiler is fundamentally ill-conceived. Right now it hardcodes the (SImode, DImode) pair. You're adding hardcoding of (QImode, SImode) as well. But really it should consider all pairs of (integer mode, wider integer mode), with the machine description (or target hooks) determining which pairs are relevant on a particular target. Changing it not to hardcode particular modes would be better than adding a second pair. That along with not hard-coding ZERO_EXTEND. Both MIPS and Alpha have much the same free operations, but with SIGN_EXTEND. I remember rejecting one iteration of this pass with this hard-coded, but the pass was apparently approved by someone else without that being corrected. r~