[MLIR][LLVM] Fix memory explosion when converting global variable bodies in ModuleTranslation (#82708)

[vzakhari]

There is memory explosion when converting the body or initializer region
of a large global variable, e.g. a constant array.

For example, when translating a constant array of 100000 strings:

llvm.mlir.global internal constant @cats_strings() {addr_space = 0 :
i32, alignment = 16 : i64} : !llvm.array<100000 x ptr> {
%0 = llvm.mlir.undef : !llvm.array<100000 x ptr>
%1 = llvm.mlir.addressof @om_1 : !llvm.ptr<array<1 x i8>>
%2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr
%3 = llvm.insertvalue %2, %0[0] : !llvm.array<100000 x ptr>
%4 = llvm.mlir.addressof @om_2 : !llvm.ptr<array<1 x i8>>
%5 = llvm.getelementptr %4[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr
%6 = llvm.insertvalue %5, %3[1] : !llvm.array<100000 x ptr>
%7 = llvm.mlir.addressof @om_3 : !llvm.ptr<array<1 x i8>>
%8 = llvm.getelementptr %7[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr
%9 = llvm.insertvalue %8, %6[2] : !llvm.array<100000 x ptr>
%10 = llvm.mlir.addressof @om_4 : !llvm.ptr<array<1 x i8>>
%11 = llvm.getelementptr %10[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr
%12 = llvm.insertvalue %11, %9[3] : !llvm.array<100000 x ptr>

... (ignore the remaining part)
}

where @om_1, @om_2, ... are string global constants.

Each time an operation is converted to LLVM, a new constant is created.
When it comes to llvm.insertvalue, a new constant array of 100000
elements is created and the old constant array (input) is not destroyed.
This causes memory explosion. We observed that, on a system with 128 GB
memory, the translation of 100000 elements got killed due to using up
all the memory. On a system with 64 GB, 65536 elements was enough to
cause the translation killed.

There is a previous patch (https://reviews.llvm.org/D148487) which fix
this issue but was reverted for
llvm#62802

The old patch checks generated constants and destroyed them if there is
no use. But the check of use for the constant is too early, which cause
the constant be removed before use.

This new patch added a map was added a map to save expected use count
for a constant. Then decrease when reach each use.
And only erase the constant when the use count reach to zero

With new patch, the repro in
llvm#62802 finished correctly.

---

Stack:

• [llvm][Support] Add support for executing a detached process (#81708) #11
• Non functional change. Initialize var EnumVal to 0. (#82987) #10
• Revert "[DSE] Test precommit for a bug caused by a read-clobber being skipped. (#83084)" #9
• [DSE] Test precommit for a bug caused by a read-clobber being skipped. (#83084) #8
• [APINotes] Fix a few accidental refactoring artifacts #7
• [libc][stdfix] Add sqrt for fixed point types. (#83042) #6
• [SelectionDAG] Remove pointer from MMO for VP strided load/store. (#82667) #5
• [mlir][sparse] Introduce batch level format. (#83082) #4
• [NFC][hwasan] Do not include sanitizer_placement_new.h in header files (#82993) #3
• Revert "[scudo] Store more blocks in each TransferBatch" (#83078) #2
• [lldb] python-bindings: fix SBTarget.get_target_watchpoints() (#82295) #1

⚠️ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.