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

[Cary Coutant <ccoutant at gmail dot com>]

> 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.

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.)

-cary

[3] https://sourceware.org/ml/binutils/2018-11/msg00263.html