[FFmpeg-devel] [RFC] Loop unrolling in C code for 'vector_fmul_*' functions

[Rich Felker]

On Thu, Jan 10, 2008 at 09:25:04PM -0500, Rich Felker wrote:
> On Fri, Jan 11, 2008 at 12:33:04AM +0000, M?ns Rullg?rd wrote:
> > Loren Merritt <lorenm at u.washington.edu> writes:
> > 
> > > On Fri, 11 Jan 2008, mark cox wrote:
> > >> On Jan 11, 2008 7:39 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > >>
> > >>> Add a assert((len & 7) == 0); and the compiler can know it.
> > >>
> > >> That is a really interesting statement. are you saying that gcc will
> > >> optimize by adding such an assert? This is the first i have heard of this.
> > >> such code annotations could probably help in many places.
> > >
> > > No, he's saying that the information is then available to the compiler, 
> > > so the above advice about complaining to the gcc devs about suboptimal 
> > > code applies.
> > >
> > > But gcc certainly does apply some such optimizations, if not specifically 
> > > assert. e.g. if you dereference a pointer and then test its truth, the 
> > > test will be optimized away because it's a constant if the dereference 
> > > didn't crash.
> > 
> > Is it wise to assume that dereferencing a null pointer will crash?
> 
> It's irrelevant. The program has undefined behavior after the null
> pointer dereference, so a valid implementation may do anything it
> wants on any conditional, or any other C construct for that matter.

To clarify: the compiler is not taking advantage of the assumption
that the program should already have crashed on NULL pointer
dereference, but rather the fact that the code has undefined behavior
if the pointer is NULL.

Rich