Bernd Schmidt writes:
> On 07/05/11 21:25, Richard Sandiford wrote:
>> A C bootstrap only should be fine of course, since the code isn't
>> going to be run.)
>>
>>> + hwloop_info loops = NULL;
>>
>> Unnecessary initialisation (or at least, it should be).
>
> ? The value is used inside the loop
On 07/05/11 21:25, Richard Sandiford wrote:
> (Could you bootstrap this on x86_64 to check for things like that?
That has no loop_end pattern so it wouldn't be much of a test, but a
x86_64 x bfin compiler has no warnings in this file with the intptr_t
thing fixed.
> A C bootstrap only should be
Bernd Schmidt writes:
>> Is there no possibility of running the optimisation in cfglayout mode
>> instead? It seems from this and the forwarder block stuff above as
>> though it might make things easier, but maybe not.
>
> I'm not sure what you mean here. This reordering isn't for the sake of
> t
On Tue, Jun 21, 2011 at 3:37 PM, Bernd Schmidt wrote:
>
> +static void
> +reorder_loops (loop_info loops)
> +{
> + basic_block bb;
> + loop_info loop;
> +
> + FOR_EACH_BB (bb)
> +bb->aux = NULL;
See clear_aux_for_blocks().
Ciao!
Steven
I suppose my main question about this is: did you consider extending
the cfgloop machinery instead of writing new loop discovery code?
Also, loop discovery seems to be based on the liveness of the iterator,
but what happens if the iterator is a general register that is spilled
for part of the loop
We currently support counted loops on several targets by having the
loop-doloop pass search for suitable loops and convert them to using the
doloop_end pattern. Unfortunately, there are various machines which have
hardware loop support, but need additional tests and transformations,
during the fina
