This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Dec 13, 2018 at 8:43 AM Michael Matz <> wrote:
> Hi,
> On Thu, 13 Dec 2018, H.J. Lu wrote:
> > > In principle, whenever you have turned on generation of the property
> > > bit, you set the associated known bit.  Now, what your OR_AND
> > > construct turns into a one bit is represented by known=1 and
> > > property=1 in the output.  But you can distinguish between the other
> > > three cases, all of which get mapped to zero by your mechanism (or
> > > absent, except that as I noted before, you can't reasonably do absent
> > > in the middle of a word of such bits).
> >
> > 1 bit isn't an issue.  0 bit is tricky.  In case of USED property, 0 bit
> > means that the feature isn't used.  When combining 2 objects, one has
> > the USED property and the other doesn't, how do you perform such OR
> > operation?
> With a logical bit-or.  The result of combining both of course has the
> feature USED.  That is when both inputs have their KNOWN/RELIABLE/VALID
> bit set for that feature.  If one of them doesn't have it set, then the
> USED bit is unreliable in this single object, and hence also in the
> result.  Which means a logical bit-and for the KNOWN bits and bit-or for
> USED bits.  That results in unknown-used here, which makes sense when
> interpreting as "feature is used but there were some unreliable inputs".
> In this specific case (combining known-used with unknown-unused) one
> might also decide to leave the KNOWN bit on (to known-used) if you know
> something about the particular feature: if the bit setting is such that
> USED is less conservative than UNUSED then unknown-unused is "at worst"
> unknown-used, which combines just fine with known-used to known-used.  But
> if you know nothing about the bits (as generic tools shouldn't) the
> correct path through this lattice of knowledge-usedness is and-or.
> (This (non)knowledge of feature specifics is actually what makes the
> difference between unknown-used and unknown-unused.  If you know what of
> used/unused is more conservative, either unknown-used can be mapped to
> known-used or unknown-unused to known-unused without loss of information.
> But you can only do that mapping if you know the semantics of the feature,
> which is why you need both states in generic tools).

For the USED property, if the KNOWN/RELIABLE/VALID isn't set, its 1 bits
are valid.  But its 0 bits are invalid.  So it contains the same information as
absence of this property.   Am I correct?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]