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


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