[PATCH] D14596: [SROA] Choose more profitable type in findCommonType

Guozhi Wei via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 9 16:50:24 PST 2015


Carrot added a comment.

In http://reviews.llvm.org/D14596#306559, @chandlerc wrote:

> I was really confused about this patch until I read the bug. =]
>
> For the record, bugs don't go to a widely followed mailing list, and so it is often helpful to provide a summary of the problem being faced when posting a patch for review in addition to a link to the bug. Otherwise it can be hard to figure out.
>
> However, I don't think this is the correct fix. Regardless of what type SROA chooses to use, the optimizer should *always* fix the type when we discover that in the end loads and stores end up feeding floating point instructions. I worked really hard to fix this exact issue so that SROA could stay simple and ignorant of such issues, and so we could continue to lower memcpy as integer loads and stores.
>
> It would really help to provide a reduced IR test case. The bug is full of C++ code and asm, but only has excerpts of the IR. The integer loads and stores should only exist within the function as long as there are no floating point operations on the loaded or stored type. The question is why that isn't proving to be the case, as there is code that tries to ensure that in the tree.


The memcpy is lowered in instruction combine pass, so you mean the root cause should be in this pass?


http://reviews.llvm.org/D14596





More information about the llvm-commits mailing list