[llvm-dev] Metadata in LLVM back-end

[Son Tuan VU via llvm-dev]

Hi,

Thank you all for keeping this going. Indeed I was not aware that the
discussion was going on, I am really sorry for this late reply.

I understand Chris' point about metadata design. Either the metadata
becomes stale or removed (if we do not teach transformations to preserve
it), or we end up modifying many (if not all) transformations to keep the
data intact.
Currently in the IR, I feel like the default behavior is to ignore/remove
the metadata, and only a limited number of transformations know how to
maintain and update it, which is a best-effort approach.
That being said, my initial thought was to adopt this approach to the MIR,
so that we can at least have a minimal mechanism to communicate additional
information to various transformations, or even dump it to the asm/object
file.
In other words, it is the responsibility of the users who introduce/use the
metadata in the MIR to teach the transformations they selected how to
preserve their metadata. A common API to abstract this would definitely
help, just as combineMetadata() from lib/Transforms/Utils/Local.cpp does.

As for my use case, it is also security-related. However, I do not consider
the metadata to be a compilation "correctness" criteria: metadata, by
definition (from the LLVM IR), can be safely removed without affecting the
program's correctness.
If possible, I would like to have more details on Lorenzo's use case in
order to see how metadata would interfere with program's correctness.

As for the RFC, I can definitely try to write one, but this would be my
first time doing so. But maybe it is better to start with Lorenzo's
proposal, as you have already been working on this? Please tell me if you
prefer me to start the RFC though.

Thank you again for keeping this going.

Sincerely,

- Son

On Wed, Nov 4, 2020 at 6:30 PM Lorenzo Casalino <
lorenzo.casalino93 at gmail.com> wrote:

>
> Le 04/11/20 à 17:40, David Greene a écrit :
> > Sorry about the late reply.
> >
> > Lorenzo Casalino <lorenzo.casalino93 at gmail.com> writes:
> >
> >>>>> - Should not impact compile time excessively (what is "excessive?")
> >>>> Probably, such estimation should be performed on
> >>> Did something get cut off here?
> >> Uops. Yep, I removed a paragraph, but, apparentely I forgot the first
> >> period. In any case, we should discuss about how to quantitatively
> >> determine an acceptable upper-bound on the overhead on the compilation
> >> time and give a motivation for it. For instance, max n% overhead on the
> >> compilation time must be guaranteed, because ** list of reasons **.
> > I am not sure how we'd arrive at such a number or motivate/defend it.
> > Do we have any sense of the impact of the existing metadata
> > infrastructure?  If not I'm not sure we can do it for something
> > completely new.  I think we can set a goal but we'd have to revise it as
> > we gain experience.
> I think it is the best approach to employ :)
> >>> Since you initially raised the topic, do you want to take the lead in
> >>> writing up a RFC?  I can certainly do it too but I want to give you
> >>> right of first refusal.  :)
> >>>                     -David
> >> Uhm...actually, it wasn't me but Son Tuan, so the right of refusal
> >> should be granted to him :) And I noticed now that he wasn't included in
> >> CC of all our mails; I hope he was able to follow our discussion
> >> anyways. I am adding him in this mail and let us wait if he has any
> >> critical feature or point to discuss.
> > Fair enough!  I have recently taken on a lot more work so unfortunately
> > I can't devote a lot of time to this at the moment.  I've got to clear
> > out my pipeline first.  I'd be very happy to help review text, etc.
> Do not worry, it is ok ;) Meanwhile we wait for any feedback/input from
> Son,
> I'll try to prepare a draft of RFC and publish it here.
>
> Thank you David, and have a nice day :)
>
> -- Lorenzo
>
> >                  -David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201109/2b56e628/attachment.html>