[llvm-dev] DAG Combine 2 Pass does not finish with -g

[via llvm-dev]

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Boris
> Boesler via llvm-dev
> Sent: Monday, September 03, 2018 5:18 AM
> To: Robinson, Paul via llvm-dev
> Subject: [llvm-dev] DAG Combine 2 Pass does not finish with -g
> 
> Hi.
> 
> For our target we have a small transformation for ADD operations that
> increases the chance to combine unindexed LOADs/STOREs and ADDs to indexed
> LOADs/STOREs. This works as expected until we use option -g for debug
> output; then even for small tests the whole memory (> 50GB) is used and we
> have to interrupt the compiler. But we can't see why that huge amount of
> memory is used.
> 
> We use LLVM 3.4.2.

3.4.2 was released over 4 years ago.  A *lot* has changed since then.

> The transformation checks if the LHS of an ADD
> operation is the base pointer of an indexed LOAD/STORE. If this is the
> case we create a new ADD with the incremented pointer as LHS and a SUB(old
> LHS, LOAD/STORE increment value) as new LHS. All unindexed LOADs/STOREs
> with the incremented pointer of the indexed LOAD/STORE as base pointer are
> pushed to the combiners work list. These new ADDs are then checked again
> recursively. (A lot more checks are done to avoid cycles within the DAG.)
> As soon as the RHS to the new ADD is a constant with value 1, LLVM's
> combiner itself can combine unindexed LOAD/STORE with this ADD to an
> indexed LOAD/STORE.
> 
> This works as expected. In a test 809 new ADDs are generated and 22 LOADs
> and 100 STOREs are pushed to the combiners work list. And a lot of a new
> indexed LOADs/STOREs are generated.
> 
> According to our target's debug output none of our functions, that could
> cause the memory usage, is called. Is there something special about
> generating debug info? Is the recursion while creating the ADDs a problem?

The recursion might be a problem. I'm far from expert in this area but what
I usually hear described is adding elements to the end of a work list, and
iterating on the work list.

Hopefully somebody with more experience in this area can give a better answer.
--paulr

> We tried "empty" SDLoc attributes while creating these new ADDs, but that
> didn't show any difference.
> 
> Any ideas what might cause that memory usage?
> Boris
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev