[clang] [Clang][CodeGen][X86] don't coerce int128 into `{i64,i64}` for SysV-like ABIs (PR #135230)

[via cfe-commits]

T0b1-iOS wrote:

> Maybe a bad suggestion, I have not looked into the implementation, but at the point where the i128 gets split into two i64s, could we already update the #dbg_value there to use fragments? At that point we have all the required information, and it sounds like it would avoid the problem since there is then no longer any larger-than-i64 debug info to cause poison?

I think would be possible but currently the code that inserts the `#dbg_declare` records (`CodeGenFunction::EmitParmDecl`) is oblivious to the splitting. It only gets handed the `i128` value that is loaded from the temporary `{i64, i64}` alloca (created in `CodeGenFunction::EmitFunctionProlog`) where both `i64` arguments are stored into. Thus you would need to add debug handling code into the part that creates the temporary alloca which would require a refactoring of the way debug info metadata is created because the code responsible for that currently creates the `#dbg_declare` records together with the metadata (c.f. `CGDebugInfo::EmitDeclare`).
Passing as i128 seems like the better choice in that case.

To solve this problem in general, it would probably(?) be best to make SROA create fragment `#dbg_value` records if it decomposes an alloca into multiple IR values but I have no idea how difficult that would be to accomplish.

> Presumably the desire here is to improve the variable availability of parameters rather than fully supporting i128's through LLVM debug-info

Yes, at least my primary motivation is for me to be able to retrieve the registers the parameter is passed in without having to rely on any crude heuristics.

https://github.com/llvm/llvm-project/pull/135230