Mrmaxmeier opened issue #3722:
The docs for
uextend
and friends mentionIf the input and output types are the same, this is a no-op.
When called with matching types, the verifier complains though:
Mrmaxmeier labeled issue #3722:
The docs for
uextend
and friends mentionIf the input and output types are the same, this is a no-op.
When called with matching types, the verifier complains though:
Mrmaxmeier labeled issue #3722:
The docs for
uextend
and friends mentionIf the input and output types are the same, this is a no-op.
When called with matching types, the verifier complains though:
Mrmaxmeier edited issue #3722:
The docs for
uextend
and friends mentionIf the input and output types are the same, this is a no-op.
When called with matching types, the verifier complains though:
(Whoops, this probably shouldn't be labeled as a bug ^^)
fitzgen commented on issue #3722:
Thanks for filing an issue.
I'd be in favor of updating the docs to match reality, rather than changing the verifier. Thoughts @cfallin?
cfallin commented on issue #3722:
@Mrmaxmeier I'm actually somewhat surprised that a uextend-T-to-T didn't work; this line
if arg_type.lane_bits() >= ctrl_type.lane_bits() {
seems to indicate that equal input and output widths (
>=
) should be fine. I think that this is a reasonable thing to support; it simplifies the producer side not to have to special-case. Could you share the input that led to this error?
Mrmaxmeier commented on issue #3722:
The
>=
condition guards the error case. Here's a.clif
:target x86_64 function %func(i64) -> i64 { block0(v0: i64): v1 = uextend.i64 v0 return v1 }
cfallin commented on issue #3722:
Urgh, you're right, I didn't read closely enough; sorry!
I looked a bit more into whether the backends would already support this or not, and it appears that at least e.g. here in the x64 backend (maybe others too) the T-to-T case isn't handled. If you want to try your hand at doing so, I'm happy to review a PR, otherwise it's probably OK to update the docs to reflect the limitation for now. We might want to come back to this as we review opcode/type-coverage completeness, though.
Last updated: Dec 23 2024 at 13:07 UTC