JonPsson1 wrote: ah, I was thinking about the LOAD_STACK_GUARD_ADDRESS preg being potentially spilled.
I guess I am not quite sure about the details about when the FI is known to go out of range. Isn't that decided during PrologEpilog insertion, after all the spill slots have been created, and FrameIndices are eliminated? If it is then out of range, a vreg is allocated and used to load the address, and the vreg is handled with the RegScavenger, but that would mean that some other value is being preemptied, but the address is now in the scavenged reg. So then it wouldn't be on the stack. Or maybe this is about when there already is e.g. a huge alloca before regalloc, so the LAY is somehow produced earlier? Maybe that should be avoided somehow so it never happens early so that it always falls back on the scavenger? I am thinking that since this is in the entry block, and in the return block(s), maybe it wouldn't be such a big loss to allocate needed regs (one for the external canary address, one for the FI address when it is out of range) as extra use operands. It would at least be simpler: one pseudo for each move/compare to be expanded late, which would also be easier to verify the location of in relation to other memory accesses. This would make this more robust against all other optimizations as well, even though those MI flags should generally be enough. But maybe the scavenger solution is better in the sense that it is only used if actually needed. https://github.com/llvm/llvm-project/pull/169317 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
