Page MenuHomePhabricator

[NFC] update LangRef for D88645
Needs RevisionPublic

Authored by Tyker on Feb 13 2021, 4:28 AM.

Details

Summary

reflect IR change in the LangRef after addition on a new parameter to llvm.ptr.annotation.* and llvm.var.annotation in d3205bbca3e0002d76282878986993e7e7994779.

Diff Detail

Event Timeline

Tyker requested review of this revision.Feb 13 2021, 4:28 AM
Tyker created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 13 2021, 4:28 AM

The text needs an update too. It talks about each argument but not the new one. Also, " and the last argument is the line number." is now clearly wrong.

Tyker updated this revision to Diff 323788.Feb 15 2021, 10:14 AM

addressed comment

andrew.w.kaylor added inline comments.
llvm/docs/LangRef.rst
19804–19805

This 'and' becomes redundant with the additional text.

19805

Can you add some information about what the additional arguments are? What exactly does this point to?

Tyker updated this revision to Diff 325715.Feb 23 2021, 1:55 AM

fixed the sentence.

Can you add some information about what the additional arguments are? What exactly does this point to?

This is not clear from the description.

Tyker updated this revision to Diff 327088.Mar 1 2021, 5:52 AM

added more details about the storage of additional arguments.

I'm not trying to be difficult, but I genuinely still don't understand the additional arguments pointer. Is it intended to allow proprietary extensions? Is there an example somewhere?

If these intrinsics are meant as a general mechanism to enable arbitrary communication between custom front ends and custom optimization passes, that's fine. I'd just like to see something explicitly explaining that.

lebedev.ri requested changes to this revision.Mar 1 2021, 10:43 AM
lebedev.ri added a subscriber: lebedev.ri.

This patch is missing a description.

This revision now requires changes to proceed.Mar 1 2021, 10:43 AM
Tyker edited the summary of this revision. (Show Details)EditedMar 8 2021, 9:39 AM

I'm not trying to be difficult, but I genuinely still don't understand the additional arguments pointer. Is it intended to allow proprietary extensions? Is there an example somewhere?

If these intrinsics are meant as a general mechanism to enable arbitrary communication between custom front ends and custom optimization passes, that's fine. I'd just like to see something explicitly explaining that.

the pointer is to a global struct containing the the provided arguments. I use it to communicate from source code to custom passes. but the front-end doesn't need to be custom. since the code to generate theses extra arguments is in clang trunk.
here is a basic example: https://godbolt.org/z/Tavcv9.
how the passes use this information is not defined it can be used for many things.
the major benefit I see is that it can pass arbitrary information and works well with template and constexpr programing. but the front-end does not do any semantic checking on the meaning of the information.