llvm dev - Sep 2018 - 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

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