Some people say "discard" has not a positive effect on optimization. Other people say it will at least spare the fetches of textures.
 

if (color.A < 0.1f) {
	//discard;
	clip(-1);
}

// tons of reads of textures following here
// and loops too

Some people say that "discard" will only mask out the output of the pixel shader, while still evaluates all the statements after the "discard" instruction.

MSN>
discard: Do not output the result of the current pixel.
clip: Discards the current pixel..
<MSN

As usual it is unclear, but it suggests that "clip" could discard the whole pixel(maybe stopping execution too)

I think, that at least, because of termal and energy consuming reasons, GPU should not evaluate the statements after "discard", but some people on internet say that GPU computes the statements anyways. What I am more worried about, are the texture fetches after discard/clip.

(what if after discard, I have an expensive branch decision that makes the approved cheap branch neighbor pixels stall for nothing? this is crazy)

Ok, I think I understand it now. When people say that GPU keeps evaluating the sentences, they actually mean the other pixels of the grid/group evaluate the sentences. It is just never clearly enough explained. I think this way, my fetches from textures from inside the discarded pixel are spared. I hate to post useless posts....

It isn't useless to ponder about it. That's how we learn, for example.

The reference documentation is very vague on purpose. It's up to the vendors how they achieve it.

Do they run none/some/all of the work in vain? Everything is legal! And they will!

Will it somehow differ between vendors and generations? You bet! Yet it will be compliant.

As long as the results match the prescription, vendor is allowed anything. That's why it's most challenging to achieve the most performant results on all PC setups; it's much easier on consoles where you can be sure about what will happen.