[LLVMdev] Scalar replacement of arrays

[Nicolas Capens]

Hi Preston,

Thanks for the suggestion. Unfortunately I don't know how to apply it to 
LLVM.

I'm struggling with the problem of spilling. Basically scalarrepl makes 
the original array alloca disappear and replaces it with individual 
scalar allocas, which then also disappear when mem2reg puts them into 
SSA form. Then register allocation puts stuff on the stack again, but 
not where the allocas were. That's a problem when you actually expect to 
be able to dynamically index the array.

I'd like the array alloca to stay where it is, but to see the same 
optimizations as achieved by scalarrepl+mem2reg in sections of code 
where no dynamic indexing is occuring, and the register allocator should 
spill and restore to/from the original array so that for dynamic 
indexing a minimal number of registers is written back to memory.

I'm starting to think this actually can't be achieved with SSA at all. 
Perhaps I shouldn't run scalarrepl and see if the optimizations can be 
performed at the register allocator level instead?

Cheers,
Nicolas


On 09/03/2012 12:34 PM, Preston Briggs wrote:
> Nicolas Capens wrote:
>> [...]
>> I'm not sure if that's going to help achieve optimal code
>> for when the array is sometimes being dynamically indexed.
>> Essentially there should be some kind of store to load copy
>> propagation. As far as I know that's exactly what mem2reg
>> does, except that it only considers scalars and not elements
>> of arrays.
>>
>> So would it be hard to extend mem2reg to also consider elements
>> of arrays for promotion? It should obviously not perform the promotion
>> when in between the store and load there's a dynamically indexed
>> access to the array. Correct me if I'm wrong, but that seems it would
>> be superior to scalarrepl itself (for arrays).
>>
>> Is there anyone experienced with mem2reg who wants to implement this?
>> If not, any advice on how to best approach this?
> Classically, we use dependence analysis to support such optimizations.
> For example, see Chapter 8 in Allen&  Kennedy's book,
> "Optimizing Compilers for Modern Architectures."
>
> Preston
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev