threadFenceReduction can not use 1024 threads per block

The Problem

If one tries to execute ./threadFenceReduction --threads=1024, it will exit with a failure without further explanation.

The Solution

The switch statements in threadFenceReduction_kernel.cuh just don't have a case for 1024 which is trivial to fix. With the fix I get significantly better performance by using 1024 threads compared to 512 or less for --n=33554432 both in the single-pass and the multi-pass case.

I have tested both single-pass and-multi-pass for several power-of-2 and random inputs, so there doesn't seem to be an algorithmic reason to limit the number of threads to 512.

One might also want to add a default case to the switches which produces a clear error message.

Start with threadFenceReduction_kernel.cuh and trace the switch statements used by ./threadFenceReduction for the --threads option. Verify single-pass and multi-pass runs with 1024 threads and the stated large --n value; done means the command no longer fails for 1024 and unsupported values produce a clear error.