[PATCH] D118376: [x86] try harder to scalarize a vector load with extracted integer op uses

Fri Feb 4 14:49:54 PST 2022

haowei added a comment.

In D118376#3296441 <https://reviews.llvm.org/D118376#3296441>, @spatel wrote:

> In D118376#3295685 <https://reviews.llvm.org/D118376#3295685>, @haowei wrote:
>
>> I am not an expert on Mac. I did some experiments. Using the clang built from this revision (b4b97ec813a02585000f30ac7d532dda74e8bfda <https://reviews.llvm.org/rGb4b97ec813a02585000f30ac7d532dda74e8bfda>) to build stage 2 clang, regardless of the revision of the second stage clang, will cause clang-refactor related test to fail.  So I think this patch introduced a bug that changed clang's code gen behavior and cause clang to generate buggy code on the Mac. I still don't quite understand why the clang-refactor tool is the only one affected so far. If you need any binaries from stage 1 and 2 build to debug this issue, please let me know. I can help build them for you.
>
> Thanks - I'll take any help I can get to reduce the bug. :)
> I have reverted the patch on main, and I think I should also revert it on the 14 branch (if you can confirm that the bug is present resolved with that revert).
>
> Is it correct that the bug is only visible on the Mac build (the same tests are not failing on other platforms)? 
> It's not clear to me from the logs what the failure is: all 5 of the tests in "clang/test/Refactor/Extract" cause clang-refactor to crash?

I can confirm the stage 2 builds are green after the revert. I am doing some local builds to see if I can generate stage 2 clang-refactor binaries with and without your patch so I can hand them to you for comparison. I am also working on simpler steps to reproduce the issue without Fuchsia related stuff to it can be easier to debug. Will file a bug in github once I get there.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118376/new/

https://reviews.llvm.org/D118376