To prove it let's look at the following simple code from the open source OpenCV library.

template<typename T, class Op> static void
cvtScale_( const Mat& srcmat, Mat& dstmat, double _scale, double _shift )
{
    Op op;
    typedef typename Op::type1 WT;
    typedef typename Op::rtype DT;
    Size size = getContinuousSize( srcmat, dstmat, srcmat.channels() );
    WT scale = saturate_cast<WT>(_scale), shift = saturate_cast<WT>(_shift);

    for( int y = 0; y < size.height; y++ )
    {
        const T* src = (const T*)(srcmat.data + srcmat.step*y);
        DT* dst = (DT*)(dstmat.data + dstmat.step*y);
        int x = 0;
        for(; x <= size.width - 4; x += 4 )
        {
            DT t0, t1;
            t0 = op(src[x]*scale + shift);
            t1 = op(src[x+1]*scale + shift);
            dst[x] = t0; dst[x+1] = t1;
            t0 = op(src[x+2]*scale + shift);
            t1 = op(src[x+3]*scale + shift);
            dst[x+2] = t0; dst[x+3] = t1;
        }
        for( ; x < size.width; x++ )
            dst[x] = op(src[x]*scale + shift);

      }
}

It is a template function working with chars, ints, shorts, floats and doubles.
And as you could see its authors decided to help to the compiler with the loop vectorization by unrolling the internal "x" loop by 4 (and processing the remaining data tail separately).

So, do you think the loop will be vectorized by the modern optimizing compilers properly?

Let's check it using  the Intel Compiler 12.0 with /QxSSE2 optimization option (using other SSEx or AVX option gives the same result as below).

And  the compiler generated assembly output is very surprising:  The compiler produces some SSE instructions however only scalar not the vector ones.  The unrolled loop is NOT vectorized, but  the remaining data tail, containing 1-3 elements in not unrolled loop, is vectorized!

If we remove the unrolling making our code simple :

for( int y = 0; y < size.height; y++ )
    {
        const T* src = (const T*)(srcmat.data + srcmat.step*y);
        DT* dst = (DT*)(dstmat.data + dstmat.step*y);
        int x = 0;
        for( ; x < size.width; x++ )
            dst[x] = op(src[x]*scale + shift);
    }

 ... and check the asm output again we find the compiler does fully vectorize the code resulting in performance increase up to 2-4 times depending on the input data type!
Conclusion: More work for unrolling - lower performance. Don't do it.

Please notice that Microsoft Compiler, Visual Studio 2010 and 2008 with /arch:SSE2 option does NOT vectorize the code above neither unrolled no the compact one.The code produced in both cases is very similar in appearence and performance. It just confirms the conclusion above.

And what if you want to keep unrolling for some reason but still need get the vectorization=performance desired?
Then use the Intel compiler pragmas as shown below:
----------------------------------------------------------
#pragma simd
   for(x=0; x <= size.width - 4; x += 4 )
        {
            DT t0, t1;
            t0 = op(src[x]*scale + shift);
            t1 = op(src[x+1]*scale + shift);
            dst[x] = t0; dst[x+1] = t1;
            t0 = op(src[x+2]*scale + shift);
            t1 = op(src[x+3]*scale + shift);
            dst[x+2] = t0; dst[x+3] = t1;
        }
#pragma novector
        for( ; x < size.width; x++ )
            dst[x] = op(src[x]*scale + shift);
      }

-----------------------------------------

It is self explaining, isn't it?

 Sounds more than good... but it is not true unfortunately. Whereas intrinsics do make the use of cpu specific enhancements easier significantly, they don't eliminate the need to do some asm programming  entirely. The problem is that intrinsics don't provide the fallback path for the systems without corresponding SIMD support - if the "intrinsics inside" program is executed on such CPU,  it crashes.  To prevent it one needs to  create the "generic code"  path and switch to\from it  depending on the host system SIMD support. And to detect this support trusty and reliably  it is necessary to use assembler! No other common solution is available yet... And the most burning issue here is the Advanced Vector Extensions support detection - the AVX is not widespread yet and requires the OS support. While the Inel AVX Programming Reference contains the asm pseudocode for AVX support detection, it is not enough. What is wanted by the most developers is some cut-and-paste  code that could be used as is even without  any assembler knowleage. And such code is available - see below. 

The asm syntax differs for the 32 and 64 bits, so you need to include the corresponding version in your project and in both cases in C\C++ code call the  isAvxSupported() function - to return 1 if  AVX is supported or zero otherwise 

 extern C" int isAvxSupported();

 AVXsupport = isAvxSupported();   // = one if supported and zero otherwise

 ----------------------------------------cpuid64.asm----------------------------------------------------

; CPUID Win64
.code   

; int isAvxSupported();
isAvxSupported proc
    xor eax, eax
    cpuid
    cmp eax, 1 ; does CPUID support eax = 1?
    jb not_supported
    mov eax, 1
    cpuid
    and ecx, 018000000h ;check 27 bit (OS uses XSAVE/XRSTOR)
    cmp ecx, 018000000h ; and 28 (AVX supported by CPU)
    jne not_supported
    xor ecx, ecx ;  XFEATURE_ENABLED_MASK/XCR0 register number = 0
    xgetbv ;  XFEATURE_ENABLED_MASK register is in edx:eax
    and eax, 110b
    cmp eax, 110b ; check the AVX registers restore at context switch
    jne not_supported
    mov eax, 1
    ret
not_supported:
    xor eax, eax
    ret
isAvxSupported endp
	END

------------------------cpuid32.asm--------------------------

.686p
.xmm
.model  FLAT

; CPUID Win32
.code   

; int isAvxSupported();
_isAvxSupported proc
    xor eax, eax
    cpuid
    cmp eax, 1 ; does CPUID support eax = 1?
    jb not_supported
    mov eax, 1
    cpuid
    and ecx, 018000000h ;check 27 bit (OS uses XSAVE/XRSTOR)
    cmp ecx, 018000000h ; and 28 (AVX supported by CPU)
    jne not_supported
    xor ecx, ecx ;  XFEATURE_ENABLED_MASK/XCR0 register number = 0
    xgetbv ;  XFEATURE_ENABLED_MASK register is in edx:eax
    and eax, 110b
    cmp eax, 110b ; check the AVX registers restore at context switch
    jne not_supported
    mov eax, 1
    ret
not_supported:
    xor eax, eax
    ret
_isAvxSupported endp
	END