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. 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? 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

From: llvm-dev [mailto:llvm-dev-bounces@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