Add an attribute into MachineFunction that tracks call site info.
Authors: @asowda, @NikolaPrica, @djtodoro, @ivanbaev
Differential D61061
[MachineFunction] Base support for call site info tracking djtodoro on Apr 24 2019, 5:14 AM. Authored by
Details Add an attribute into MachineFunction that tracks call site info. Authors: @asowda, @NikolaPrica, @djtodoro, @ivanbaev
Diff Detail
Event TimelineComment Actions Do we ever see ourselves supporting anything except registers here?
Comment Actions I think this is the first type of entry in MIR that references instructions directly, and it seems quite easy to forget to update the offset in the block when adding/removing instructions, but I guess checking for ranges and if the instruction is a call might help. @qcolombet, did anything like this come up in the past?
Comment Actions
Not that I know of and I agree this seems very fragile. Side question, I thought the right way to fix that was to provide better APIs to query ABI lowering information for debugger and other tools. Adding this information here seems a step in a wrong direction. Comment Actions -Add a helper function for initialization of call site info Comment Actions Maybe it would be better to use a call instruction number? For example, use {id: 1} for first call instruction in MIR stream instead of {bb: 0 , offset: 3}? Or use {bb:0 , ID: 1} for the first instruction in basic block 0?
@qcolombet Thanks for participating in this! Call ABI lowering happens at ISEL stage so we thought that it is the right place to collect information about it and preserve it inside MF. We are open for suggestions to try out. Please provide us with more details about your idea. Comment Actions
When we lower a call we invoke some method to do the lowering to register, frame index etc. The idea would be to extract this code (easier said than done) into its own library and use this API to produce the debug info instead of carrying this information in the MachineFunction. Comment Actions Thanks for the suggestion. Sorry for the late response. This would indeed be very useful. We think that there are too many difficulties for bringing such API. In order to provide such API, we would need to know what function is called with the MIR call instruction in order to invoke APIs lowering process for that function. This should be easy for direct calls, (i.e. we have pointer to global function and we could somehow invoke lowering process for it, yet there is the question: how we should handle variadic function calls). However, for indirect calls we cannot think of any good way. Some kind of mapping between an IR call instruction and the MIR call instruction is needed for that (but this again requires carrying additional information and it is not suitable for other tools I suppose). Different mapping could possibly be achieved by debug/source location of the MIR call instruction. Basically, that is extracting information from the source code. That does not sound good at all! If we ignore the fact that we significantly raise the complexity of this feature with such approach, calling fronted procedures in order to reconstruct the calling context smells like significant overhead at least. Currently we are inserting additional code in call lowering methods to collect call arguments forwarding information. If someone comes up with good solution, the only thing that needs to be changed is the place where we store collected information and to remove all code that updates MachineFunction’s call site info through the backend. Comment Actions minor nitpick inside.
|