No, I don't agree with what you said in your post, and you make a lot of invalid proofs by contradiction.
The first pass of your optimizer took a valid program and made an invalid one. That should be the end of the article, but then you ran further (presumably valid) optimization passes which led to erroneous results.
Using Modus Tollens and De Morgan's. Instead you declare that casts have side-effects, dive into "integer provenance", make some distinction between "as" casts and transmute, and so on. Meanwhile, I conclude that broken optimizer passes should be fixed or removed.
> I would argue that the alternative is to treat the original program (after translation to Rust) as having Undefined Behavior.
I'm sure you'll get your way, and you probably won't stop until Rust has as many tricky "undefined behaviors" for the compiler to exploit as they do in C. Programmers will need a masters degree in "provenance" to avoid the traps you set for them. Then when they stumble and fall in the pit you dug, they can go to the forums and be chastised by the experts. You'll get some .1% speedup on a non-realistic benchmark and declare it a job well done.
> There are, to my knowledge, generally two reasons why people might want to transmute a pointer to an integer
This "argument by lack of imagination" strategy isn't sound either. What if you just haven't thought of a third reason yet?
> I think we should move towards discouraging, deprecating, or even entirely disallowing pointer-integer transmutation in Rust. That means a cast is the only legal way to turn a pointer into an integer
It's really unclear to me why the compiler can't recognize that transmuting a pointer to an integer is the same as a cast. And if it can recognize that, why make it UB?!? Maybe this is all about those 129 bit CHERI pointers. If you want to break the compiler for just that platform, more power to you.
Really, I don't care if you break transmute, so long you leave a way to cast function pointers:
The first pass of your optimizer took a valid program and made an invalid one. That should be the end of the article, but then you ran further (presumably valid) optimization passes which led to erroneous results.
Your whole argument seems to look like:
Since we can't have erroneous optimizations, you make a faulty conclusion the problem is pointer to integer round trips. You even say it here:> However, the only possibly suspicious part of the original program is a pointer-integer-pointer round-trip
But it's not the only suspicious part, so all of your following statements are questionable. The contradiction should've led you to:
Using Modus Tollens and De Morgan's. Instead you declare that casts have side-effects, dive into "integer provenance", make some distinction between "as" casts and transmute, and so on. Meanwhile, I conclude that broken optimizer passes should be fixed or removed.> I would argue that the alternative is to treat the original program (after translation to Rust) as having Undefined Behavior.
I'm sure you'll get your way, and you probably won't stop until Rust has as many tricky "undefined behaviors" for the compiler to exploit as they do in C. Programmers will need a masters degree in "provenance" to avoid the traps you set for them. Then when they stumble and fall in the pit you dug, they can go to the forums and be chastised by the experts. You'll get some .1% speedup on a non-realistic benchmark and declare it a job well done.
> There are, to my knowledge, generally two reasons why people might want to transmute a pointer to an integer
This "argument by lack of imagination" strategy isn't sound either. What if you just haven't thought of a third reason yet?
> I think we should move towards discouraging, deprecating, or even entirely disallowing pointer-integer transmutation in Rust. That means a cast is the only legal way to turn a pointer into an integer
It's really unclear to me why the compiler can't recognize that transmuting a pointer to an integer is the same as a cast. And if it can recognize that, why make it UB?!? Maybe this is all about those 129 bit CHERI pointers. If you want to break the compiler for just that platform, more power to you.
Really, I don't care if you break transmute, so long you leave a way to cast function pointers:
https://rust-lang.github.io/unsafe-code-guidelines/layout/fu...