[9/*] This is what makes it so hard to work with CLANG for optimized code :( You never have any idea when it is going to critically break. You may carefully inspect some part of your code, and verify that it compiles to sane ASM... but it can change radically from a version bump.
-
Show this thread
-
[10/*] And furthermore, since the optimizer changes so dramatically from release to release, they may fix something broken (resulting in a speed win) and break something else (speed loss), so you can't even just use benchmarks to know things didn't regress.
1 reply 0 retweets 14 likesShow this thread -
[11/*] You can use a profile to know the _total_ speed of your program didn't get slower, but several parts may have gotten slower due to CLANG optimizer freakouts, and as long as they improved other parts as much (or more!), you won't even know until you reanalyze manually.
2 replies 0 retweets 13 likesShow this thread -
[12/*] I am not an optimization person. I maybe spend a week every three months looking at ASM. This has happened to me _three times in the last year_. It's almost 100% of the time I've looked at CLANG ASM, I have hit something like this.
1 reply 0 retweets 16 likesShow this thread -
[13/*] I'm not sure what the solution to this problem is. But I do think it would be a nice start for people to recognize that it _is_ a problem, because I think it really is.
3 replies 0 retweets 16 likesShow this thread -
Replying to @cmuratori
The solution is to file bug reports. Nobody wants bad codegen.
1 reply 0 retweets 0 likes -
Replying to @al45tair
My point with this thread is that that is not a solution. Constantly breaking codegen is the problem. Filing bug reports just continues the cycle of constantly breaking codegen. The solution is to fix the process to that the compiler does not have codegen regressions.
2 replies 0 retweets 1 like -
Replying to @cmuratori
The fix for that is for the compiler to have tests that exercise the cases you care about. The way that happens is for you to file bug reports. Otherwise we don’t know what you care about, and might not know it’s broken.
1 reply 0 retweets 0 likes -
Replying to @al45tair
I'm not sure I can make this any clearer. You can't file a bug report _for something that you don't know happened_. What was I supposed to file a bug report on? Code that _was_ working, so they would know not to break it??
1 reply 0 retweets 1 like -
Replying to @cmuratori
No. When it breaks, file a bug report. Then someone will (a) fix it and (b) add tests to make sure it doesn’t get broken again. I know it’s annoying, but the reality is that compilers are large programs and sometimes things get broken. The test suite is how we avoid that.
1 reply 0 retweets 0 likes
Let me just move the needle back to the beginning of the record and turn the volume up: THE POINT IS THAT CLANG CODEGEN BREAKS CONSTANTLY FOR ME ON TRIVIAL CODE. THIS THREAD IS ME TRYING TO SAY THAT THE SHIPPING PROCESS IS BROKEN. OTHER COMPILERS DO NOT SEEM TO HAVE THIS PROBLEM.
-
-
Replying to @cmuratori @al45tair
TELLING PEOPLE TO FILE BUG REPORTS IS NOT A SOLUTION TO A PROCESS WHEREBY TRIVIAL CODE HAS VERY BAD CODEGEN ALL THE TIME. IT POINTS TO AN INHERENT PROBLEM IN THE WAY THE CODE IS MAINTAINED OR TESTED THAT NEEDS TO BE FIXED.
2 replies 0 retweets 2 likes -
Replying to @cmuratori @al45tair
You can insert the scratchy sounds of the needle moving off the record now.
1 reply 0 retweets 2 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.