-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EncodeUtf8 iterator implementation results in bad code #35099
Comments
Maybe it's a problem that EncodeUtf8::next() isn't marked |
Yes, I was writing code inside libstd (libcore, rather), so the method got inlined regardless of attribute (or lack of it thereof). |
I looked into this a bit; there are a few related problems, but I think the biggest problem is that LLVM can't really figure out that accesses to EncodeUtf8.buf don't alias accesses to EncodeUtf8.pos, which prevents a lot of simplifications. There's been some discussion of this on the LLVM mailing lists; see http://lists.llvm.org/pipermail/llvm-dev/2016-July/102867.html and http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html . |
Not relevant anymore as a different approach is now used, that generates pretty nice code. |
Provided #35098 (more precisely f729e17 commit) lands, iterating
x.encode_utf8().as_slice()
results in considerably better code compared tox.encode_utf8()
.One major problem with the
EncodeUtf8
iterator is the fact that it uses checked indexing, despite it being obvious this iterator cannot index out-of-bounds. However, even if that problem is fixed, noticeably worse code is still generated, but I couldn’t exactly pinpoint why.cc @alexcrichton #32204
The text was updated successfully, but these errors were encountered: