Alexei Starovoitov writes: > On Fri, Apr 19, 2019 at 02:33:10PM -0700, Jakub Kicinski wrote: >> On Fri, 19 Apr 2019 14:14:05 -0700, Alexei Starovoitov wrote: >> > > This reminds me, I'm not entirely clear on the need to propagate the >> > > zext through stack slots... Pointers are guaranteed to be 64bit, we >> > > don't save parentage on scalars (AFAICT), >> > >> > scalars have parentage chain too. >> > we don't track them precisely when they're spilled to stack. >> > That actually caused an issue recently when valid program was rejected, >> > so we might add a feature to track full contents of scalars in the stack. >> >> Interesting.. >> >> > > why not pass REG_LIVE_READ >> > > or READ64 to mark_reg_read() from stack_read? >> > >> > can we agree on only two states first ? ;) >> >> Yess, the LIVE_READ was thought to be more of a mask for those accesses >> that only care about "any read" being set, to be honest. As you said >> read64 is a strict superset of read32. Keeping the name REG_LIVE_READ, >> rather than REG_LIVE_READ_ANY or _MASK let us leave some of the >> existing code untouched. >> >> Jiong's original idea was to add a read32, and have read mean read64. >> >> I think you said we should have read32 and read64 flags, but clear >> read32 once read64 gets set? SGTM! > > yep. > > any subsequent read64 means that earlier read32 marks are irrelevant > from zext optimization pov. OK, will split REG_LIVE_READ into REG_LIVE_READ64 and REG_LIVE_READ32, and will let the prior override the latter early inside mark_reg_read. I feel renaming parameter for propagate_liveness (the "parent" etc) could be a following up patch? Let me know if you want it included in this set. (I am travelling, will try to send out updated version around next Tuesday) Regards, Jiong
