A test case that reproduces a tail replication bug (exposed by URNG of AMD SDK 
after adding a barrier to the loop).
Fixed a kernel compiler bug when handling a b-loop with multiple
latches.

The problem was threefold:

1) Detection of the need to "peel" the wiloop was faulty: post-dominance
check does not work in this case as the another branch leads always to
exit via the back edge, thus is post-dominated even though it should be
handled as a diverging region. Fixed this by counting the number of
parallel regions sharing the entry block and assuming if there are more
than one, the PR is a diverging one and should be peeled.

2) The parallel region was not found for the another latch created by
the barrier tail replication. It assumed there can be only one latch
barrier.

3) Barrier tail replication failed to replicate the latch due thinking
the PHI node values should all come from the replicated block. The
PHI node values in this case originate from the "shared" part of
the replicated diverging parallel region so there was no own copy for
the variable in the replicated part. Now it simply falls back to using
the original one in this case.
Skip the the as_type test on PowerPC - it fails undeterministically with 
corrupt data for large vector types (int/uint/float16). 
It works when pocl is built with --enable-debug, fails when built without.
As --enable-debug doesn't affect the kernel compilation (and indeed the
genereated code is the same in both cases), it seems this is an alignment
error. Further evindence towards this is that the test started to fail 
when altivec was enabled, the and the kernel uses 'lvx' instructions, that
require 16-byte aligned data.

Could not isolate the error, so I don't know if this is a pocl or LLVM bug :(