This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] x86: Don't remove empty x86 properties
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Jim Dehnert <dehnert at gmail dot com>, x86-64-abi <x86-64-abi at googlegroups dot com>, Binutils <binutils at sourceware dot org>
- Date: Fri, 7 Dec 2018 15:16:58 -0800
- Subject: Re: [PATCH] x86: Don't remove empty x86 properties
- References: <firstname.lastname@example.org> <CAJimCsHhUNTbMrO5uDfkaRVJSGz6QaJK3vBPbbpYGHE0mPirEA@mail.gmail.com> <CAMe9rOqNwUxYTYN1xVdrpSc9VC16tnxAYuzvgJvGAacE6W5eMQ@mail.gmail.com> <CAJimCsHdzQF8dwQUO5Yeg8RjZVOxOmVbdtBXFbLBEqGKnNAV0g@mail.gmail.com> <CAJimCsHwHoiB+mFozJeeL9Cux5-9bJA2Vu0VAAWsDtJGoXUv8w@mail.gmail.com> <CAMe9rOrdHAg6KNLXXvrbkLPxehi6yodOPzchZuHY9B+3ayQ7SA@mail.gmail.com> <CAJimCsH+8X=UC-EaeR0H8iVS67yLc-DK9PzSrHFnzoRP_thNPQ@mail.gmail.com> <CAMe9rOri3Osi9d6db-+EFw3bcp7tWG12ytx5rebcpaVSa2id_A@mail.gmail.com> <CAJimCsEwWqqWxnTNrXZ+AhcBVovjOdb33O=VE2eKpJ6baMHFQA@mail.gmail.com> <CAMe9rOoB5unY6MOL8DmTWDo2gkbwBOHRvj0oxZ2E3SK8t4VO3A@mail.gmail.com> <CAJimCsEuD+Cgq_zSbTMxTPjbPouB9i729FxgaB3=p-ccA=cNtA@mail.gmail.com> <CAMe9rOrwbiAmyL3=KDstQmwrxKVZ6odrma71s_fOx-vUdnPaVg@mail.gmail.com> <CAJimCsFHjvgZaCDmhOPd+1iD_HJqhKmn6jiy72PSXBugt04a6Q@mail.gmail.com> <CAMe9rOoJSUQtWE=BmhXFKsfO=CoB56RK+8uEC25btgoThSN1email@example.com> <CAJimCsHR2ixUqqLAiHvr6j+a3XDOgstbNRcTq_s_82dsNgs01Q@mail.gmail.com> <CAMe9rOoKQsJpkfVauOaYwbydb4OF=dOGq3fmOFW=bjOiyui5Vw@mail.gmail.com> <CAJimCsExxWio=XbjeTFBKiCb1+0h9jmWjfkojns1PCsAtEw5BQ@mail.gmail.com> <CAMe9rOrsBr916FEWZce3FhnpKsNczS0pCo0aj7-7SEQK1aAh6g@mail.gmail.com> <CAJimCsEYfFvDNfZ2+dNZEDSWmHAzzuzXbL3yohus_OFu9G-zTw@mail.gmail.com> <CAMe9rOpLVcMz-ONEYWZ0nhcg+Bsc6yoeb42ktUbijG3i_kb2Ew@mail.gmail.com> <CAJimCsF0OJU=cwkftmm_T9AZVaiomFp4fNKErNeN7gmVSMTGKg@mail.gmail.com> <CAMe9rOrdxpU60NfXBCPTrudYQffAPzA1odDDGha9ZruM2VNawg@mail.gmail.com> <CAPWn4jd7mM3nrHLXMF_oEu2q=y9t1XV0sDzD10W4yK+2uVG-vA@mail.gmail.com> <CAMe9rOpB-O3o+dFePkR-WWK=kZsN_054GK_yhxpBwbQNwdh-eA@mail.gmail.com> <CAJimCsGHV82KyXF-ms0gTXyx=zmRXZ-KwJWQA-HtPozF6=+e0A@mail.gmail.com>
On Fri, Dec 7, 2018 at 9:12 AM Cary Coutant <firstname.lastname@example.org> 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 , 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.