Talking about this sort of thing can get a bit complicated, since there's actually a layered approach to how shaders execute on a GPU. Your HLSL code is compiled to D3D bytecode, which is a bunch of instructions and declarations for a virtual ISA. When you actually bind that shader at runtime and use it, the driver will JIT compile the virtual ISA bytecode into the actual ISA used by the GPU. It's actually a bit like CLR/.NET in this regard, in that you have different semantics for both the virtual machine and the actual hardware. So to simplify things, I'm mostly just going to talk about D3D's virtual ISA here since there's such a wide variety of GPU's out in the wild.

The D3D shader ISA does not have any concept of a stack. So there is possibility of your array being placed into the stack, and read from there.The ISA can only read values from registers, or from a buffers/textures. Which one of these it uses will depend on how you declare the array, and also on the code that uses the array. In your particular case, it primarily depends on whether you declare your array in a constant buffer and whether or not the compiler unrolls your for loop. The first part is simple: if you declare your array inside of a cbuffer declarataion, or declare as a global without the "static" modifier, then the array data will be loaded out of a constant buffer. The second part is a bit more complicated. In general the HLSL compiler likes to unroll loops whenever it can, which is typically when the number of iterations is known at compile time. In your case the number of iterations is fixed at 16, and so its likely that the compiler will unroll the loop. If it unrolls the loop and your array is marked as constant (doesn't come from a buffer), then the compiler can essentially inline your array data right into the code generated for the unrolled loop. This can be nice, since it removes the need for any memory accessing instructions when using the array data. However it also results in more total program instructions compared to using flow control instructions. Note that you can try to force the compiler to unroll the loop by using the [unroll] attribute on your for loop. If the compiler doesn't unroll the loop and instead uses dynamic flow control instructions (either because the loop count isn't known, or because you used the [loop] attribute), then the compiler will no longer be able to directly embed your array values into the code, since the same code is used for each loop iteration. It also can't just pre-load the array values into a bunch of registers, since the D3D ISA lacks the ability to dynamically index into registers. So what it will typically do is embed your array values into a compiler-generated constant buffer. This is a special constant buffer that the driver manages transparently, and it allows the shader program to dynamically index into the array using memory instructions.

With all of that said, I would recommend keeping the code the way you have it. Doing it that way should allow the compiler to unroll the loop, which is usually good from a performance point of view. Not only will you avoid memory accesses from reading the values out of a constant buffer, but unrolling can also give the hardware a better opportunity to pipeline your shadow map texture fetches in order to hide latency.