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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
