clock skew vs clock latency

Thanks for replying, Kaz. Yes, obviously, the input delay of method (2) is 0.5 bigger than that of method (1). But, so is the source latency component in the data required path, as shown in my attached timing report. (method (2) reports 0.5 in its source latency while method (1) reports 0). So the 0.5 difference actually gets cancelled off in the calculation of setup slack and it does not have an effect on the final result.

What really makes a difference to the final result is some other value (Inter Connection) in the timing path, which I marked with a red box in the attached timing report. It seems that the same logic element is put in different locations by these two methods

(FF_X1_Y8_N21 in method (1) vs FF_X2_Y13_N9 in method (2)), which results in different Inter Connection delays and the final slacks.

Since the compiler behaves differently with these two methods as constraints, which method is preferred if we want to achieve a better timing result?

Does method (1) (using clock skew instead of set clock latency) always achieves a better timing result than method (2), or vice versa?