Add vector overloads for or and and #4529
Conversation
| [__unsafeForceInlineEarly] | ||
| [OverloadRank(-10)] | ||
| vector<bool, N> and<let N : int>(bool b, vector<bool, N> v) | ||
| { | ||
| return and(vector<bool, N>(b), v); | ||
| } | ||
|
|
||
| [__unsafeForceInlineEarly] | ||
| [OverloadRank(-10)] | ||
| vector<bool, N> and<let N : int>(vector<bool, N> v, bool b) | ||
| { | ||
| return and(v, vector<bool, N>(b)); | ||
| } |
There was a problem hiding this comment.
I am not sure if we should support this function that may lead to inefficient code.
A proper implementation for this should happen at the application level in a following manner,
vector<bool,N> result = (b? v : vector<bool,N>(false));
There was a problem hiding this comment.
@chaoticbob for an opinion.
There was a problem hiding this comment.
What makes you think it would be inefficient? Probably best left to the eventual backend to determine precisely what combination of conditional move and bitand is best.
I agree with not supporting it for different reasons (to avoid proliferation of overloads), but this ship has sailed because hlsl already supports this.
There was a problem hiding this comment.
I'm trying to catch up here, is the question here if a vectorized version of the and (and also or) intrinsic can lead to inefficient code?
There was a problem hiding this comment.
Hmmm. Right.
I think "?:" is probably more efficient than vectorized "and" operation.
There was a problem hiding this comment.
If I'm reading this correctly, the question is about the efficiency of anding a vector and a scalar. For SPIR-V this compiles down an OpCompositeConstruct for the scalar to expand to a vector followed by OpLogicalAnd to perform the vectorized and operation. DXIL handles it with individual instructions per component.
As @expipiplus1 alluded to, it's difficult to gauge how efficient or inefficient this will be for the driver level shader compiler. Driver level shader compilers may have specialized instructions or patterns to handle these cases.
In addition to HLSL already supporting it, it's generally not good idea to be overly prescriptive about how application level code should be written, especially in cases where expression is awkwardly limited in the interest of potential efficiency.
There was a problem hiding this comment.
Ok. I guess the downstream compiler will be able to optimize it out.
Closes #4441 and #4434