Re: [PATCH] x86: Don't remove empty x86 properties

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Dec 7, 2018 at 9:12 AM Cary Coutant <ccoutant@gmail.com> wrote:
>
> > The above are general observations.  There's a more subtle issue
> > in this particular proposal that's related (as I understand it).
> > Because you're packing property bits into larger units, and will
> > presumably be adding additional properties in the future, you'll
> > want to be able to tell which bits are valid in a particular
> > object (e.g., was it created before or after the new property was
> > added?).  Otherwise, bits might be zero either because the
> > property isn't true, or because it wasn't supported by the tool
> > that created the object.  You can't really deal with this using
> > version information, because there's no good way to combine
> > versions without discarding information.  I'd suggest including a
> > "complete" bit for each property bit, meaning that all components
> > of the object provided valid values for the property.
> > Non-complete property bits could still contain useful data, but a
> > consumer could not assume it was a valid combination of all the
> > component objects.  (This implies that the complete bits are all
> > AND bits - the output value should be an AND of all the input
> > values when combining objects.)   Note that the separate complete
> > bits removes the need for the OR_AND construct, which was trying
> > to combine two separate concepts in a single bit.
> >
> > Thanks Jim.  Your description pretty much captures my intention.
> > OR_AND provides a way to
> > mark an object with complete info.  If the bit is 1, the feature
> > exists.  If the bit is 0, the feature does
> > not exist.  A "complete" bit is an interesting idea.   How should it
> > be mapped to NEEDED and USED
> > properties? I have
>
> This brings us back to what I was talking about in [3], where I
> suggested using FEATURE_X_KNOWN and FEATURE_X_NEEDED properties. What
> Jim calls "complete" bits are what I called "known" bits.
>
> Basically, every producer that generates a set of NEEDED properties
> would also generate a corresponding set of KNOWN properties, which
> consist of all ones for the properties that the producer knows about
> at the time. These would be ANDed together, while the NEEDED
> properties would be ORed together. In the final executable, you'd have
> a set of KNOWN bits that indicate whether the value for that property
> is known in all inputs, and a set of NEEDED bits that indicate whether
> the property was needed by at least one input. If a NEEDED bit is 1,
> you know that feature is needed. If a NEEDED bit is 0, and the KNOWN
> bit is 1, you know that feature is not needed. Otherwise (KNOWN bit is
> 0 and NEEDED bit is 0), it is unknown.

NEEDED bits are tricky.  The 1 NEEDED bit on object should only be set
by programmer.   A programmer knows that AVX512 is needed and can
set AVX512 NEEDED bit to 1.  But he/she may not know if other ISAs
are NOT needed.  So for NEEDED bits, marking 0 bits as known or
complete isn't that easy.

> You could use known/complete bits for ISA_1_USED, ISA_1_NEEDED,
> FEATURE_2_USED, and FEATURE_2_NEEDED. If you always generate both USED
> and NEEDED bits, you might be able to get away with one ISA_1_KNOWN
> for both ISA_1_USED and ISA_1_NEEDED, and one FEATURE_2_KNOWN for both
> FEATURE_2_USED and FEATURE_2_NEEDED. But since you are currently
> generating only USED bits, and NEEDED bits will presumably come later,
> you'll probably want a separate set of KNOWN bits for each property.
>
> (I'm still questioning the usefulness of the USED bits, though.)

USED bits as defined in x86-64 psABI can generated by assembler and
linker automatically.   This can only be done with OR_AND rule.

-- 
H.J.