This function was not taking into account that the
input type could be a vector, and wasn't properly
working for vector types.
This caused an assert when building spec2k6 perlbmk for armv8.
Differential D12559
Fix IRBuilder CreateBitOrPointerCast for vector types sbaranga on Sep 2 2015, 9:33 AM. Authored by
Details This function was not taking into account that the This caused an assert when building spec2k6 perlbmk for armv8.
Diff Detail Event TimelineComment Actions Verified, this patch fixes the crash in http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/20070/steps/build%20llvm-symbolizer%20android%2Farm/logs/stdio Comment Actions LGTM, too. A test case might be hard to produce, but I can give you four candidates:
Because this patch is the solution to broken bots, I accept it going as is, without test, for now. Because the original patch did not break our bots straight away (on self-hosting clang), I think it triggers more Clang-alignment problems, but that's for a different investigation. Please commit. You can work on the test on a subsequent commit. cheers, Comment Actions Hi Silviu, What was the assertion and why didn't we get it when you tested specs before? Is the data that you posted before on the performance/code size/compile time still valid? Thanks,
Comment Actions Almost minimized test case, build with --target=armv7-linux-gnueabi -std=c++11 -O2 -c class A { char *Data; int Length; public: A() : Data(), Length() {} }; A *resize_I; void m_fn1() { for (auto E = m_fn2(); resize_I != E; ++resize_I) new (resize_I) A; } A *m_fn2(); }; class C { void m_fn3(B &) const; }; Comment Actions Hi, Thanks for the reduced testcase! The assertion was caused by a call to this function (CreateBitOrPointerCast) from a <4 x struct.. *> to <4 x i32> (which is similar with this case). I don't think it should assert in this case. I didn't see these problems in my testing. The benchmark was compiling fine and producing valid results. The fact that we are seeing these issues is strange. Could it be caused by some parallel commit? The testing results should still be valid. I don't have access to my testing setup at the moment. I'll try to fix this as soon as I can (in about 9 hours?). Thanks,
Comment Actions Hi, I've committed this in r246759 to unbreak the bots. Thanks,
Comment Actions I've also investigated how we missed this issue: there is no spec2k6 data (just for aarch64) on the ARM review. For ARM we just had lnt/spec2k data. I think the most recent run that I had for ARM with spec2k6 and interleaved accesses enabled was from about 2 months ago (which is why I was sure that I did run this on ARM). Thanks, |
This doesn't look right. What if we have vectors of different sizes (i.e. V is <8 x i32> and DestTy is <4 x i32>)?