[llvm-commits] [llvm] r48909 - /llvm/trunk/lib/Transforms/Scalar/GVN.cpp

[Chris Lattner]

On Mar 28, 2008, at 9:15 AM, Duncan Sands wrote:

> Hi Chris,
>
>>> is this counting bytes stored, or store instructions?
>>
>> This is checking # stores.  I'm open to suggestions, this is  
>> certainly
>> work in progress.  The idea is that merging just a few stores could  
>> be
>> done by the code generator, turning them into a larger scalar store.
>
> it just doesn't seem canonical, while counting the number of bytes is.

Fair enough. The idea was that merging 8 i8 stores is more important  
than merging 2 i32 stores.

> By the way, how about turning 4 i8 stores into an i32 store here if  
> you
> think it's not worth doing a memset?  (Watch out for creating  
> unaligned
> stores!).

I'd much rather have GVN just make a memset, and then have something  
else (e.g. instcombine) turn it into a scalar store if possible.  This  
puts the memset -> scalar logic in one place that gets used by other  
code as well.


>> What I want the optimizer to get is to turn huge sequences of stores
>> into memset.  For example, the testcase I'm working from looks like:
>
> ... snip example with a tiny number of stores :) ...
>
> Also, are you planning to synthesize memset out of loops?  (Please  
> say yes!)

I'd love to do this some day (it would be a huge win for many apps),  
but I don't have short term plans for it.  It would be pretty easy to  
write a LoopPass up that recognizes the simple and obvious case (which  
is also the most common!), but we really need dependence analysis to  
handle the more general case.

It probably makes sense to do a loop pass to handle the case of a loop  
with a single store in it, whose pointer is a GEP, whose index is a  
SCEV that is obviously linearly increasing.  Replacing this simple  
loop with a memset would capture a huge number of the important cases  
(e.g. those loops in viterbi).

-Chris