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.
