[llvm-dev] DAG Combine 2 Pass does not finish with -g (original) (raw)

via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 4 08:27:18 PDT 2018

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

More information about the llvm-dev mailing list