Re: [PATCH V3 4/7] ira: Support subreg copy
On 2023/11/18 16:24, Sam James wrote: Lehua Ding writes: Hi Sam, On 2023/11/18 16:06, Sam James wrote: Lehua Ding writes: Hi Vladimir, On 2023/11/17 22:05, Vladimir Makarov wrote: On 11/16/23 21:06, Lehua Ding wrote: Hi Vladimir, Thank you so much for your review. Based on your comments, I feel like there are a lot of issues, especially the long compile time issue. So I'm going to reorganize and refactor the patches so that as many of them as possible can be reviewed separately. this way there will be fewer patches to support subreg in the end. I plan to split it into four separate patches like bellow. What do you think? I can wait for the new version patches. The only issue is stage1 deadline. In my opinion, I'd recommend to work on the patches more and start their submission right before GCC-14 release (somewhere in April). Quite agree, I'll rewrite the patches a bit better before resend new version patchs, stage 1 is definitely too late. When you say before GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 I should have to wait until GCC 15 stage 1. I took it to mean "submit it during GCC 14 stage 3 for merging during GCC 15 stage 1", as the idea would be that if you're basing it on the state of the tree & doing further/final testing on GCC 14 stage 3, the tree should be in a stable state by then with only regression fixes going in, rather than other changes which might disrupt your testing. This means you are not constantly rebasing and getting new test failures possibly due to changes other than yours. It also means lots of time to review and fix any problems with less pressure. Oh, looks like I misunderstood. Thanks for the correction. You need a lot of testing for the patches: major targets (x86-64, aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing how even small changes in RA can affect many targets, e.g. GCC testsuite results (there are a lot of different target tests which expect a particular output), it is better to do this on stabilized GCC and stage3 is the best time for this. In any case I'll approve patches only if you have successful bootstraps and no GCC testsuite regression on x86-64, ppc64le/be, aarhc64, i686. Also you have a lot of compile time performance issues which you need to address. So I guess you will be overwhelmed by new different target PRs after committing the patches if you will do this now. You will have more time and less pressure work if you commit these patches in April. Hm, I'll test the targets I can get first. I'll figure out the other targets later. The compiler farm can provide access to a bunch of targets and the community may be able to help with access to others if needed. I applied for cfarm access the other day, I'll try to use it. Thanks. No problem. If you need some Linux targets not on the cfarm, let me know. I can probably help with hppa/sparc at least and I know someone with alpha, mips. That's great. Thanks in advance. -- Best, Lehua (RiVAI)
Re: [PATCH V3 4/7] ira: Support subreg copy
Lehua Ding writes: > Hi Sam, > > On 2023/11/18 16:06, Sam James wrote: >> Lehua Ding writes: >> >>> Hi Vladimir, >>> >>> On 2023/11/17 22:05, Vladimir Makarov wrote: On 11/16/23 21:06, Lehua Ding wrote: > Hi Vladimir, > > Thank you so much for your review. Based on your comments, I feel > like there are a lot of issues, especially the long compile time > issue. So I'm going to reorganize and refactor the patches so that > as many of them as possible can be reviewed separately. this way > there will be fewer patches to support subreg in the end. I plan to > split it into four separate patches like bellow. What do you think? > I can wait for the new version patches. The only issue is stage1 deadline. In my opinion, I'd recommend to work on the patches more and start their submission right before GCC-14 release (somewhere in April). >>> >>> Quite agree, I'll rewrite the patches a bit better before resend new >>> version patchs, stage 1 is definitely too late. When you say before >>> GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit >>> such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 >>> I should have to wait until GCC 15 stage 1. >> I took it to mean "submit it during GCC 14 stage 3 for merging >> during >> GCC 15 stage 1", as the idea would be that if you're basing it on the >> state of the tree & doing further/final testing on GCC 14 stage 3, >> the tree should be in a stable state by then with only regression fixes >> going in, rather than other changes which might disrupt your testing. >> This means you are not constantly rebasing and getting new test >> failures >> possibly due to changes other than yours. It also means lots of time to >> review and fix any problems with less pressure. > > Oh, looks like I misunderstood. Thanks for the correction. > >>> You need a lot of testing for the patches: major targets (x86-64, aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing how even small changes in RA can affect many targets, e.g. GCC testsuite results (there are a lot of different target tests which expect a particular output), it is better to do this on stabilized GCC and stage3 is the best time for this. In any case I'll approve patches only if you have successful bootstraps and no GCC testsuite regression on x86-64, ppc64le/be, aarhc64, i686. Also you have a lot of compile time performance issues which you need to address. So I guess you will be overwhelmed by new different target PRs after committing the patches if you will do this now. You will have more time and less pressure work if you commit these patches in April. >>> >>> Hm, I'll test the targets I can get first. I'll figure out the >>> other targets later. >>> >> The compiler farm can provide access to a bunch of targets and the >> community may be able to help with access to others if needed. > > I applied for cfarm access the other day, I'll try to use it. Thanks. No problem. If you need some Linux targets not on the cfarm, let me know. I can probably help with hppa/sparc at least and I know someone with alpha, mips.
Re: [PATCH V3 4/7] ira: Support subreg copy
Hi Sam, On 2023/11/18 16:06, Sam James wrote: Lehua Ding writes: Hi Vladimir, On 2023/11/17 22:05, Vladimir Makarov wrote: On 11/16/23 21:06, Lehua Ding wrote: Hi Vladimir, Thank you so much for your review. Based on your comments, I feel like there are a lot of issues, especially the long compile time issue. So I'm going to reorganize and refactor the patches so that as many of them as possible can be reviewed separately. this way there will be fewer patches to support subreg in the end. I plan to split it into four separate patches like bellow. What do you think? I can wait for the new version patches. The only issue is stage1 deadline. In my opinion, I'd recommend to work on the patches more and start their submission right before GCC-14 release (somewhere in April). Quite agree, I'll rewrite the patches a bit better before resend new version patchs, stage 1 is definitely too late. When you say before GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 I should have to wait until GCC 15 stage 1. I took it to mean "submit it during GCC 14 stage 3 for merging during GCC 15 stage 1", as the idea would be that if you're basing it on the state of the tree & doing further/final testing on GCC 14 stage 3, the tree should be in a stable state by then with only regression fixes going in, rather than other changes which might disrupt your testing. This means you are not constantly rebasing and getting new test failures possibly due to changes other than yours. It also means lots of time to review and fix any problems with less pressure. Oh, looks like I misunderstood. Thanks for the correction. You need a lot of testing for the patches: major targets (x86-64, aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing how even small changes in RA can affect many targets, e.g. GCC testsuite results (there are a lot of different target tests which expect a particular output), it is better to do this on stabilized GCC and stage3 is the best time for this. In any case I'll approve patches only if you have successful bootstraps and no GCC testsuite regression on x86-64, ppc64le/be, aarhc64, i686. Also you have a lot of compile time performance issues which you need to address. So I guess you will be overwhelmed by new different target PRs after committing the patches if you will do this now. You will have more time and less pressure work if you commit these patches in April. Hm, I'll test the targets I can get first. I'll figure out the other targets later. The compiler farm can provide access to a bunch of targets and the community may be able to help with access to others if needed. I applied for cfarm access the other day, I'll try to use it. Thanks. -- Best, Lehua (RiVAI)
Re: [PATCH V3 4/7] ira: Support subreg copy
Lehua Ding writes: > Hi Vladimir, > > On 2023/11/17 22:05, Vladimir Makarov wrote: >> On 11/16/23 21:06, Lehua Ding wrote: >>> Hi Vladimir, >>> >>> Thank you so much for your review. Based on your comments, I feel >>> like there are a lot of issues, especially the long compile time >>> issue. So I'm going to reorganize and refactor the patches so that >>> as many of them as possible can be reviewed separately. this way >>> there will be fewer patches to support subreg in the end. I plan to >>> split it into four separate patches like bellow. What do you think? >>> >> I can wait for the new version patches. The only issue is stage1 deadline. >> In my opinion, I'd recommend to work on the patches more and start >> their submission right before GCC-14 release (somewhere in April). > > Quite agree, I'll rewrite the patches a bit better before resend new > version patchs, stage 1 is definitely too late. When you say before > GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit > such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 > I should have to wait until GCC 15 stage 1. I took it to mean "submit it during GCC 14 stage 3 for merging during GCC 15 stage 1", as the idea would be that if you're basing it on the state of the tree & doing further/final testing on GCC 14 stage 3, the tree should be in a stable state by then with only regression fixes going in, rather than other changes which might disrupt your testing. This means you are not constantly rebasing and getting new test failures possibly due to changes other than yours. It also means lots of time to review and fix any problems with less pressure. > >> You need a lot of testing for the patches: major targets (x86-64, >> aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing >> how even small changes in RA can affect many targets, e.g. GCC >> testsuite results (there are a lot of different target tests which >> expect a particular output), it is better to do this on stabilized >> GCC and stage3 is the best time for this. In any case I'll approve >> patches only if you have successful bootstraps and no GCC testsuite >> regression on x86-64, ppc64le/be, aarhc64, i686. >> Also you have a lot of compile time performance issues which you >> need to address. So I guess you will be overwhelmed by new >> different target PRs after committing the patches if you will do >> this now. You will have more time and less pressure work if you >> commit these patches in April. > > Hm, I'll test the targets I can get first. I'll figure out the > other targets later. > The compiler farm can provide access to a bunch of targets and the community may be able to help with access to others if needed. thanks, sam
Re: [PATCH V3 4/7] ira: Support subreg copy
Hi Vladimir, On 2023/11/17 22:05, Vladimir Makarov wrote: On 11/16/23 21:06, Lehua Ding wrote: Hi Vladimir, Thank you so much for your review. Based on your comments, I feel like there are a lot of issues, especially the long compile time issue. So I'm going to reorganize and refactor the patches so that as many of them as possible can be reviewed separately. this way there will be fewer patches to support subreg in the end. I plan to split it into four separate patches like bellow. What do you think? I can wait for the new version patches. The only issue is stage1 deadline. In my opinion, I'd recommend to work on the patches more and start their submission right before GCC-14 release (somewhere in April). Quite agree, I'll rewrite the patches a bit better before resend new version patchs, stage 1 is definitely too late. When you say before GCC-14 release do you mean at GCC 14 stage 3? Is it possible to commit such changes at stage 3? I was thinking that if I miss GCC 14 stage 1 I should have to wait until GCC 15 stage 1. You need a lot of testing for the patches: major targets (x86-64, aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing how even small changes in RA can affect many targets, e.g. GCC testsuite results (there are a lot of different target tests which expect a particular output), it is better to do this on stabilized GCC and stage3 is the best time for this. In any case I'll approve patches only if you have successful bootstraps and no GCC testsuite regression on x86-64, ppc64le/be, aarhc64, i686. Also you have a lot of compile time performance issues which you need to address. So I guess you will be overwhelmed by new different target PRs after committing the patches if you will do this now. You will have more time and less pressure work if you commit these patches in April. Hm, I'll test the targets I can get first. I'll figure out the other targets later. You changes are massive and in a critical part of GCC, it is better to do all of this on public git branch in order to people can try this and test their targets. Okay, I'll try. But it is up to you to decide when submit the patches. Still besides approval of your patches, you need successful testing. If new testsuite failures occur after submitting the patch and they are not fixed during short period of time, the patches should be reverted. 1. live_subreg problem 2. conflict_hard_regs check refactoring 3. use object instead of allocno to create copies 4. support subreg coalesce 4.1 ira: Apply live_subreg data to ira 4.2 lra: Apply live_subreg data to lra 4.3 ira: Support subreg liveness track 4.4 lra: Support subreg liveness track So for the two patches about LRA, maybe you can stop review and wait for the revised patchs. Sure. So far I only had a quick glance on them. -- Best, Lehua (RiVAI)
Re: [PATCH V3 4/7] ira: Support subreg copy
On 11/16/23 21:06, Lehua Ding wrote: Hi Vladimir, Thank you so much for your review. Based on your comments, I feel like there are a lot of issues, especially the long compile time issue. So I'm going to reorganize and refactor the patches so that as many of them as possible can be reviewed separately. this way there will be fewer patches to support subreg in the end. I plan to split it into four separate patches like bellow. What do you think? I can wait for the new version patches. The only issue is stage1 deadline. In my opinion, I'd recommend to work on the patches more and start their submission right before GCC-14 release (somewhere in April). You need a lot of testing for the patches: major targets (x86-64, aarhc64, ppc64), some big endian targets, a 32-bit targets. Knowing how even small changes in RA can affect many targets, e.g. GCC testsuite results (there are a lot of different target tests which expect a particular output), it is better to do this on stabilized GCC and stage3 is the best time for this. In any case I'll approve patches only if you have successful bootstraps and no GCC testsuite regression on x86-64, ppc64le/be, aarhc64, i686. Also you have a lot of compile time performance issues which you need to address. So I guess you will be overwhelmed by new different target PRs after committing the patches if you will do this now. You will have more time and less pressure work if you commit these patches in April. You changes are massive and in a critical part of GCC, it is better to do all of this on public git branch in order to people can try this and test their targets. But it is up to you to decide when submit the patches. Still besides approval of your patches, you need successful testing. If new testsuite failures occur after submitting the patch and they are not fixed during short period of time, the patches should be reverted. 1. live_subreg problem 2. conflict_hard_regs check refactoring 3. use object instead of allocno to create copies 4. support subreg coalesce 4.1 ira: Apply live_subreg data to ira 4.2 lra: Apply live_subreg data to lra 4.3 ira: Support subreg liveness track 4.4 lra: Support subreg liveness track So for the two patches about LRA, maybe you can stop review and wait for the revised patchs. Sure. So far I only had a quick glance on them.
Re: [PATCH V3 4/7] ira: Support subreg copy
Hi Vladimir, Thank you so much for your review. Based on your comments, I feel like there are a lot of issues, especially the long compile time issue. So I'm going to reorganize and refactor the patches so that as many of them as possible can be reviewed separately. this way there will be fewer patches to support subreg in the end. I plan to split it into four separate patches like bellow. What do you think? 1. live_subreg problem 2. conflict_hard_regs check refactoring 3. use object instead of allocno to create copies 4. support subreg coalesce 4.1 ira: Apply live_subreg data to ira 4.2 lra: Apply live_subreg data to lra 4.3 ira: Support subreg liveness track 4.4 lra: Support subreg liveness track So for the two patches about LRA, maybe you can stop review and wait for the revised patchs. On 2023/11/17 5:13, Vladimir Makarov wrote: On 11/12/23 07:08, Lehua Ding wrote: This patch changes the previous way of creating a copy between allocnos to objects. gcc/ChangeLog: * ira-build.cc (find_allocno_copy): Removed. (find_object): New. (ira_create_copy): Adjust. (add_allocno_copy_to_list): Adjust. (swap_allocno_copy_ends_if_necessary): Adjust. (ira_add_allocno_copy): Adjust. (print_copy): Adjust. (print_allocno_copies): Adjust. (ira_flattening): Adjust. * ira-color.cc (INCLUDE_VECTOR): Include vector. (struct allocno_color_data): Adjust. (struct allocno_hard_regs_subnode): Adjust. (form_allocno_hard_regs_nodes_forest): Adjust. (update_left_conflict_sizes_p): Adjust. (struct update_cost_queue_elem): Adjust. (queue_update_cost): Adjust. (get_next_update_cost): Adjust. (update_costs_from_allocno): Adjust. (update_conflict_hard_regno_costs): Adjust. (assign_hard_reg): Adjust. (objects_conflict_by_live_ranges_p): New. (allocno_thread_conflict_p): Adjust. (object_thread_conflict_p): Ditto. (merge_threads): Ditto. (form_threads_from_copies): Ditto. (form_threads_from_bucket): Ditto. (form_threads_from_colorable_allocno): Ditto. (init_allocno_threads): Ditto. (add_allocno_to_bucket): Ditto. (delete_allocno_from_bucket): Ditto. (allocno_copy_cost_saving): Ditto. (color_allocnos): Ditto. (color_pass): Ditto. (update_curr_costs): Ditto. (coalesce_allocnos): Ditto. (ira_reuse_stack_slot): Ditto. (ira_initiate_assign): Ditto. (ira_finish_assign): Ditto. * ira-conflicts.cc (allocnos_conflict_for_copy_p): Ditto. (REG_SUBREG_P): Ditto. (subreg_move_p): New. (regs_non_conflict_for_copy_p): New. (subreg_reg_align_and_times_p): New. (process_regs_for_copy): Ditto. (add_insn_allocno_copies): Ditto. (propagate_copies): Ditto. * ira-emit.cc (add_range_and_copies_from_move_list): Ditto. * ira-int.h (struct ira_allocno_copy): Ditto. (ira_add_allocno_copy): Ditto. (find_object): Exported. (subreg_move_p): Exported. * ira.cc (print_redundant_copies): Exported. --- gcc/ira-build.cc | 154 +++- gcc/ira-color.cc | 541 +++ gcc/ira-conflicts.cc | 173 +++--- gcc/ira-emit.cc | 10 +- gcc/ira-int.h | 10 +- gcc/ira.cc | 5 +- 6 files changed, 646 insertions(+), 247 deletions(-) The patch is mostly ok for me except that there are the same issues I mentioned in my 1st email. Not changing comments for functions with changed interface like function arg types and names (e.g. find_allocno_copy) is particularly bad. It makes the comments confusing and wrong. Also using just "adjust" in changelog entries is too brief. You should at least mention that function signature is changed. diff --git a/gcc/ira-build.cc b/gcc/ira-build.cc index a32693e69e4..13f0f7336ed 100644 --- a/gcc/ira-build.cc +++ b/gcc/ira-build.cc diff --git a/gcc/ira-color.cc b/gcc/ira-color.cc index 8aed25144b9..099312bcdb3 100644 --- a/gcc/ira-color.cc +++ b/gcc/ira-color.cc @@ -20,6 +20,7 @@ along with GCC; see the file COPYING3. If not see - ira_allocno_t next_thread_allocno; + ira_object_t *next_thread_objects; + /* The allocno all thread shared. */ + ira_allocno_t first_thread_allocno; + /* The offset start relative to the first_thread_allocno. */ + int first_thread_offset; + /* All allocnos belong to the thread. */ + bitmap thread_allocnos; It is better to use bitmap_head instead of bitmap. It permits to avoid allocation of bitmap_head for bitmap. There are many places when bitmap_head in you patches can be better used than bitmap (it is especially profitable if there is significant probability of empty bitmap). Of course the patch cab be committed when all the patches are approved and fixed. -- Best, Lehua (RiVAI)
Re: [PATCH V3 4/7] ira: Support subreg copy
On 11/12/23 07:08, Lehua Ding wrote: This patch changes the previous way of creating a copy between allocnos to objects. gcc/ChangeLog: * ira-build.cc (find_allocno_copy): Removed. (find_object): New. (ira_create_copy): Adjust. (add_allocno_copy_to_list): Adjust. (swap_allocno_copy_ends_if_necessary): Adjust. (ira_add_allocno_copy): Adjust. (print_copy): Adjust. (print_allocno_copies): Adjust. (ira_flattening): Adjust. * ira-color.cc (INCLUDE_VECTOR): Include vector. (struct allocno_color_data): Adjust. (struct allocno_hard_regs_subnode): Adjust. (form_allocno_hard_regs_nodes_forest): Adjust. (update_left_conflict_sizes_p): Adjust. (struct update_cost_queue_elem): Adjust. (queue_update_cost): Adjust. (get_next_update_cost): Adjust. (update_costs_from_allocno): Adjust. (update_conflict_hard_regno_costs): Adjust. (assign_hard_reg): Adjust. (objects_conflict_by_live_ranges_p): New. (allocno_thread_conflict_p): Adjust. (object_thread_conflict_p): Ditto. (merge_threads): Ditto. (form_threads_from_copies): Ditto. (form_threads_from_bucket): Ditto. (form_threads_from_colorable_allocno): Ditto. (init_allocno_threads): Ditto. (add_allocno_to_bucket): Ditto. (delete_allocno_from_bucket): Ditto. (allocno_copy_cost_saving): Ditto. (color_allocnos): Ditto. (color_pass): Ditto. (update_curr_costs): Ditto. (coalesce_allocnos): Ditto. (ira_reuse_stack_slot): Ditto. (ira_initiate_assign): Ditto. (ira_finish_assign): Ditto. * ira-conflicts.cc (allocnos_conflict_for_copy_p): Ditto. (REG_SUBREG_P): Ditto. (subreg_move_p): New. (regs_non_conflict_for_copy_p): New. (subreg_reg_align_and_times_p): New. (process_regs_for_copy): Ditto. (add_insn_allocno_copies): Ditto. (propagate_copies): Ditto. * ira-emit.cc (add_range_and_copies_from_move_list): Ditto. * ira-int.h (struct ira_allocno_copy): Ditto. (ira_add_allocno_copy): Ditto. (find_object): Exported. (subreg_move_p): Exported. * ira.cc (print_redundant_copies): Exported. --- gcc/ira-build.cc | 154 +++- gcc/ira-color.cc | 541 +++ gcc/ira-conflicts.cc | 173 +++--- gcc/ira-emit.cc | 10 +- gcc/ira-int.h| 10 +- gcc/ira.cc | 5 +- 6 files changed, 646 insertions(+), 247 deletions(-) The patch is mostly ok for me except that there are the same issues I mentioned in my 1st email. Not changing comments for functions with changed interface like function arg types and names (e.g. find_allocno_copy) is particularly bad. It makes the comments confusing and wrong. Also using just "adjust" in changelog entries is too brief. You should at least mention that function signature is changed. diff --git a/gcc/ira-build.cc b/gcc/ira-build.cc index a32693e69e4..13f0f7336ed 100644 --- a/gcc/ira-build.cc +++ b/gcc/ira-build.cc diff --git a/gcc/ira-color.cc b/gcc/ira-color.cc index 8aed25144b9..099312bcdb3 100644 --- a/gcc/ira-color.cc +++ b/gcc/ira-color.cc @@ -20,6 +20,7 @@ along with GCC; see the file COPYING3. If not see - ira_allocno_t next_thread_allocno; + ira_object_t *next_thread_objects; + /* The allocno all thread shared. */ + ira_allocno_t first_thread_allocno; + /* The offset start relative to the first_thread_allocno. */ + int first_thread_offset; + /* All allocnos belong to the thread. */ + bitmap thread_allocnos; It is better to use bitmap_head instead of bitmap. It permits to avoid allocation of bitmap_head for bitmap. There are many places when bitmap_head in you patches can be better used than bitmap (it is especially profitable if there is significant probability of empty bitmap). Of course the patch cab be committed when all the patches are approved and fixed.
[PATCH V3 4/7] ira: Support subreg copy
This patch changes the previous way of creating a copy between allocnos to
objects.
gcc/ChangeLog:
* ira-build.cc (find_allocno_copy): Removed.
(find_object): New.
(ira_create_copy): Adjust.
(add_allocno_copy_to_list): Adjust.
(swap_allocno_copy_ends_if_necessary): Adjust.
(ira_add_allocno_copy): Adjust.
(print_copy): Adjust.
(print_allocno_copies): Adjust.
(ira_flattening): Adjust.
* ira-color.cc (INCLUDE_VECTOR): Include vector.
(struct allocno_color_data): Adjust.
(struct allocno_hard_regs_subnode): Adjust.
(form_allocno_hard_regs_nodes_forest): Adjust.
(update_left_conflict_sizes_p): Adjust.
(struct update_cost_queue_elem): Adjust.
(queue_update_cost): Adjust.
(get_next_update_cost): Adjust.
(update_costs_from_allocno): Adjust.
(update_conflict_hard_regno_costs): Adjust.
(assign_hard_reg): Adjust.
(objects_conflict_by_live_ranges_p): New.
(allocno_thread_conflict_p): Adjust.
(object_thread_conflict_p): Ditto.
(merge_threads): Ditto.
(form_threads_from_copies): Ditto.
(form_threads_from_bucket): Ditto.
(form_threads_from_colorable_allocno): Ditto.
(init_allocno_threads): Ditto.
(add_allocno_to_bucket): Ditto.
(delete_allocno_from_bucket): Ditto.
(allocno_copy_cost_saving): Ditto.
(color_allocnos): Ditto.
(color_pass): Ditto.
(update_curr_costs): Ditto.
(coalesce_allocnos): Ditto.
(ira_reuse_stack_slot): Ditto.
(ira_initiate_assign): Ditto.
(ira_finish_assign): Ditto.
* ira-conflicts.cc (allocnos_conflict_for_copy_p): Ditto.
(REG_SUBREG_P): Ditto.
(subreg_move_p): New.
(regs_non_conflict_for_copy_p): New.
(subreg_reg_align_and_times_p): New.
(process_regs_for_copy): Ditto.
(add_insn_allocno_copies): Ditto.
(propagate_copies): Ditto.
* ira-emit.cc (add_range_and_copies_from_move_list): Ditto.
* ira-int.h (struct ira_allocno_copy): Ditto.
(ira_add_allocno_copy): Ditto.
(find_object): Exported.
(subreg_move_p): Exported.
* ira.cc (print_redundant_copies): Exported.
---
gcc/ira-build.cc | 154 +++-
gcc/ira-color.cc | 541 +++
gcc/ira-conflicts.cc | 173 +++---
gcc/ira-emit.cc | 10 +-
gcc/ira-int.h| 10 +-
gcc/ira.cc | 5 +-
6 files changed, 646 insertions(+), 247 deletions(-)
diff --git a/gcc/ira-build.cc b/gcc/ira-build.cc
index a32693e69e4..13f0f7336ed 100644
--- a/gcc/ira-build.cc
+++ b/gcc/ira-build.cc
@@ -36,9 +36,6 @@ along with GCC; see the file COPYING3. If not see
#include "cfgloop.h"
#include "subreg-live-range.h"
-static ira_copy_t find_allocno_copy (ira_allocno_t, ira_allocno_t, rtx_insn *,
-ira_loop_tree_node_t);
-
/* The root of the loop tree corresponding to the all function. */
ira_loop_tree_node_t ira_loop_tree_root;
@@ -520,6 +517,16 @@ find_object (ira_allocno_t a, poly_int64 offset,
poly_int64 size)
return find_object (a, subreg_start, subreg_nregs);
}
+/* Return object in allocno A for REG. */
+ira_object_t
+find_object (ira_allocno_t a, rtx reg)
+{
+ if (has_subreg_object_p (a) && read_modify_subreg_p (reg))
+return find_object (a, SUBREG_BYTE (reg), GET_MODE_SIZE (GET_MODE (reg)));
+ else
+return find_object (a, 0, ALLOCNO_NREGS (a));
+}
+
/* Return the object in allocno A which match START & NREGS. Create when not
found. */
ira_object_t
@@ -1503,27 +1510,36 @@ initiate_copies (void)
/* Return copy connecting A1 and A2 and originated from INSN of
LOOP_TREE_NODE if any. */
static ira_copy_t
-find_allocno_copy (ira_allocno_t a1, ira_allocno_t a2, rtx_insn *insn,
+find_allocno_copy (ira_object_t obj1, ira_object_t obj2, rtx_insn *insn,
ira_loop_tree_node_t loop_tree_node)
{
ira_copy_t cp, next_cp;
- ira_allocno_t another_a;
+ ira_object_t another_obj;
+ ira_allocno_t a1 = OBJECT_ALLOCNO (obj1);
for (cp = ALLOCNO_COPIES (a1); cp != NULL; cp = next_cp)
{
- if (cp->first == a1)
+ ira_allocno_t first_a = OBJECT_ALLOCNO (cp->first);
+ ira_allocno_t second_a = OBJECT_ALLOCNO (cp->second);
+ if (first_a == a1)
{
next_cp = cp->next_first_allocno_copy;
- another_a = cp->second;
+ if (cp->first == obj1)
+ another_obj = cp->second;
+ else
+ continue;
}
- else if (cp->second == a1)
+ else if (second_a == a1)
{
next_cp = cp->next_second_allocno_copy;
- another_a = cp->first;
+ if (cp->second == obj1)
+ another_obj = cp->first;
+ else
+ continue;
}
else
gcc_unreachable ();
- if (another_a == a2 && c
