On 12/14/2017 03:22 PM, Aaron Sawdey wrote:
>>
>> Understood. But what I still struggle with is how you're getting
>> into
>> check_simple_exit to begin with and whether or not that should be
>> happening.
>>
>>
>> The only way to get into check_simple_exit is via find_simple_exit
>> which
>> is only called from get_simple_loop_desc.
>>
>> And if you're calling get_simple_loop_desc, then there is some kind
>> of
>> loop structure in place AFAICT that contains this insn which is
>> rather
>> surprising.
So here's what I was looking for...
loop-doloop.c will iterate over all the recorded loops, regardless of
whether or not they are "simple" loops to see if they can be converted
into a do-looop.
For each loop considered we call get_simple_loop_desc which looks like this:
struct niter_desc *desc = simple_loop_desc (loop);
if (desc)
return desc;
/* At least desc->infinite is not always initialized by
find_simple_loop_exit. */
desc = ggc_cleared_alloc<niter_desc> ();
iv_analysis_loop_init (loop);
find_simple_exit (loop, desc);
loop->simple_loop_desc = desc;
return desc;
If we already have a descriptor, return it. Else allocate a new one,
call the IV analysis code, then find_simple_loop_exit.
I must have mis-read this code multiple times. Clearly we can get to
find_simple_exit which in turn calls check_simple_exit. The call to
get_condition is guarded by a !any_condjump_p early return. But
any_condjump_p should return true for your new insn.
So the path to get_condition is reasonable. That's really all I needed
to have verified one way or the other.
With that in mind your patch is fine.
I will note that I find it highly confusing that we attach a simple loop
descriptor to a loop that is not a simple loop. But clearly you didn't
introduce that oddball behavior.
jeff
