nickdesaulniers added a comment.

Nice! Diff 466919 fixes up my confusion regarding Slot vs SlotID.  Though I do 
like how the Slots are sorted, since it keeps the Offsets in order FWICT. Maybe 
we could drop the SlotID column, then print out Slot for the variables, rather 
than the SlotID? I mean, I only really care about the Offset in the order of 
Slot, so maybe an aggressive suggestion would be to drop Slot and SlotID 
columns. (Yes, that's more work for the pretty printer to do, but it makes it 
clearer to the developer debugging the warning). Or print the variable 
identifier as a column in the table (thought that might upset the nice table 
alignment).  Do we ever re-use stack slots for different variables with 
non-overlapping live ranges? If so, then a stack slot is potentially 
one-to-many variables, so putting it in a table might not look great.

For the next potential improvement: I think DWARF (when present) contains 
information about which variables where spilled where on the stack.  It looks 
like they are not part of `MF.getVariableDbgInfo()`. Maybe we can print that 
information, too?  If a particular variable is being spilled often, then the 
developer may be able to shorten the live range manually somehow, like 
re-materialization.

In D135488#3844204 <https://reviews.llvm.org/D135488#3844204>, @paulkirth wrote:

> In D135488#3844117 <https://reviews.llvm.org/D135488#3844117>, 
> @nickdesaulniers wrote:
>
>> What does `Fixed` mean?
>
> FrameInfo has a notion of a "Fixed" slot.  From 
> `MachineFrameInfo::CreateFixedObject`'s docstring `"All fixed objects should 
> be created before other objects are created for efficiency. By default, fixed 
> objects are not pointed to by LLVM IR values. This returns an index with a 
> negative value."`
>
> I figured that may be important for people to know/see, so I left it in. It 
> doesn't mean much to me though, and I've thought about dropping it.

I'm definitely going to forget that. Perhaps it makes sense to document it 
somewhere?  Otherwise it might just be adding noise.

Seems like our initial slots are contiguous with Fixed allocations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135488/new/

https://reviews.llvm.org/D135488

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to