Re: Compiler optimization doing strange things
Re: Compiler optimization doing strange things
- Subject: Re: Compiler optimization doing strange things
- From: Ben Weiss <email@hidden>
- Date: Mon, 15 May 2006 03:10:59 -0700
On May 15, 2006, at 2:58 AM, Jan E. Schotsman wrote:
On 15-mei-06, at 10:56, Steve Checkoway wrote:
I'm seeing some very strange interactions with altivec and compiler
optimizations that I'm hoping someone can explain to me. The basic
algorithm I'm writing is:
[...]
Three questions:
1. Why does the compiler not do loop unrolling when I use size &
~0x7?
Dunno. Ask on the Altivec list.
It's not an Altivec question. The loop optimizers look for loops that
will repeat at least N times, so it can perform N-way unrolling. This
is trivial to calculate when the test is an arithmetic inequality,
but generally not when the test is a bitfield operation. The compiler
is evidently not smart enough to equate (size & ~0x7) with (size >=
8), even though they're equivalent, so it falls back on the simpler
non-unrolled behavior.
2. When the compiler does unroll the loop why does it not interleave
the independent instructions?
I have seen this with CodeWarrior too. When I switched on 'loop
unrolling' it just repeated the loops without rescheduling. If the
processor can reschedule on the fly to some extent this may still
be beneficial.
I often have to do unrolling by hand to get decent optimization, and
even do the scheduling by hand some of the time. What's obnoxious is
when I have a loop (at the head or tail of a function) that I know
will execute less than four times, but the compiler unrolls it four-
way anyway, and dynamically tests for whether or not to use the
unrolled loop. Sure, branch prediction will make the runtime impact
minimal, but it's still obnoxious.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden