[PATCH] D82316: [LangRef] Add `noundef` attribute to documentation

[Nikita Popov via Phabricator via llvm-commits]

nikic added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1258
+    any uninitialized or poison bits, the behavior is undefined. This constraint does
+    not apply to inferrable uninitialized bits, such as the 24 bits of
+    padding in `{ i8, i32 }`.
----------------
efriedma wrote:
> guiand wrote:
> > nikic wrote:
> > > I don't understand what "inferable" is intended to mean in this context.
> > Quoting from other comments here:
> > 
> > > For aggregate types, I think it is okay to relax this constraint to allowing aggregates with undef padding bits. It will be great if an aggregate value that is constructed with a chain of v = insertvalue (insertvalue undef, const1, idx), const2, idx2 can have this attribute attached regardless of whether the aggregate type has paddings or not. Inspecting padding bits which are not accessible without using memory operation may be overly restrictive.
> > 
> > > From MSan point of view, if {i8, i32} is passed as a call argument, we don't care about the padding in the middle - the type definition has all we need to understand which bits must be checked for definedness, and we'd like the attribute to reflect that - i.e. the property of the IR value itself and not its storage representation.
> > 
> > This is what I tried to capture with this description. Is there some better way I might express this succinctly?
> Not sure we have any existing terminology to describe this concept.
> 
> C++ calls these bits "pading bits" (vs. the "value representation").  Maybe we need a section in LangRef to describe this.  Probably doesn't belong specifically in the discussion of the meaning of noundef, though, since it applies more generally.  Maybe add some description in the definition of struct/array types, and link to it from here.
I think if you replace "inferable" with "inaccessible" or "unobservable", that would be more obvious. At least, I don't think there is any way to access/observe these padding bits or even their existence from LLVM IR (without a pre-existing pointer indirection).


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

https://reviews.llvm.org/D82316