[PATCH] D30416: [InstCombine] Redo reduceLoadOpStoreWidth in instcombine for bitfield store optimization.

[Friedman, Eli via llvm-commits]

On 3/6/2017 11:06 AM, Wei Mi wrote:
> After looking at the benchmark motivating the test, I find it is much 
> harder for codegenprepare to catch all the shrinking opportunities 
> compared with instcombine, because of two things:
>
> * loadpre may merge the original load in a shrinking pattern with 
> other load in a very early position, and there maybe other stores in 
> between. The safety check for the codegenprepare now simply scan 
> mayWriteToMemory insns between load and store in the candidate 
> shrinking pattern, and it will fail because of those stores in between.

It would be easy to make the check a lot more powerful using MemorySSA; 
I guess you don't have access to that in the passes where you're doing 
the transform?

> * we may see the following pattern. a.f1 is a bitfield. Ideally, we 
> should do the shrinking for all the three stores. But codegenprepare 
> works in top-down order. After the first store is shrinked, it is hard 
> for the second and the third to know %bf.set is the same as the value 
> loaded from %0. If we do this in instcombine, it is much easier 
> because before load/store elimination, %bf.set will be loaded from %0 
> respecitively in if.then9 and in if.end41.

I'm not following how it helps to do this in instcombine?  Normally, 
EarlyCSE runs first.  (A complete C testcase might be useful here.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project