<<, >>, >>>: use intrinsics for more mixed-type shift operations. #11629
Conversation
LLVM isn't able to eliminate the additional checks done by fallbacks for the mixed-type bitshift operations, so this change just calls the intrinsics directly, which minimizes the amount of work done. The fallback now avoids conversion checking as well and just returns zero if the second argument is too large to fit in an Int.
|
Hmm, the Travis failures are OOMs; I can't tell if this AppVeryor failure is related or not: https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.5508/job/phrpb8w8mm2fv0a7 It seems unrelated. I really wish our online CI stuff was more reliable in general :-\ |
|
I'm seeing the same failure on other PRs and this seems unrelated so I'm going to merge. |
<<, >>, >>>: use intrinsics for more mixed-type shift operations.
|
The Windows Failure is probably related to #11606 |
The OOM's are perhaps the fault of the "online CI," but the blame for most intermittent test errors isn't due to where the tests are running. |
|
Yes and no. If we had our own CI infrastructure, it would be much easier to isolate and reproduce problems. It would also be much faster. As it is, I find myself waiting hours for AppVeyor to run tests – and we're paying for that service. |
|
We do have our own CI infrastructure. http://buildbot.e.ip.saba.us:8010/builders It shows more or less the same set of failures. Sorry, but the unreliability is largely bugs in the language and runtime. If you want AppVeyor to run faster, there's an easy answer - pay for another worker. |
|
Paying for another worker might be worthwhile. |
|
Well if the buildbots ran on every PR I think everyone would be fine using this instead of travis. As long as there is a link from the PR page I don't think anyone cares for the fancy javascript stdout log ui. |
|
I agree with that. |
|
They don't currently, but with sufficient github webhook plumbing they could (and send statuses back too). They also aren't running the tests on the Windows buildbots, there was something about redirecting the io that caused it to act strangely last time we tried that. |
LLVM isn't able to eliminate the additional checks done by fallbacks
for the mixed-type bitshift operations, so this change just calls
the intrinsics directly, which minimizes the amount of work done.
The fallback now avoids conversion checking as well and just returns
zero if the second argument is too large to fit in an Int.