This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR47612


On 04/13/2011 01:45 AM, Michael Matz wrote:
> And is there any chance to transform this:
> 
> +#ifdef HAVE_cc0
> +         if (!sets_cc0_p (insn))
> +#endif
> +           max_to = insn;
> 
> into this:
> 
> +         if (!sets_cc0_p (insn))
>             max_to = insn;
> 
> ?  Yes, that implies making sets_cc0_p be always there and return false, 
> and write the conditionals in the corrent way?

The correct fix is to eliminate cc0 targets.

> I'll also note that the first hunk of your change is in a loop commented 
> with "Compute upper bound, bla ...", meaning to be a heuristic, and your 
> second change is this:

It's not a heuristic. Both of these loops are necessary to compute a
valid end point. !sets_cc0_p is just an additional condition that must
be satisfied in both of them.

> -         if (!bitmap_intersect_p (test_set, local_merge_live))
> +         if (!bitmap_intersect_p (test_set, local_merge_live)
> +#ifdef HAVE_cc0
> +             && !sets_cc0_p (insn)
> +#endif
> +             )
> 
> It seems to me, that those insn then shouldn't have been in test_set from 
> the start, instead of fiddling with the users of test_set.  Hence, is my 
> feeling of the patch being a hack-around of a deeper problem or it being 
> the wrong place to hack wrong?

I don't understand this sentence.


Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]