This is an archive of the discontinued LLVM Phabricator instance.

[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.

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.

I was reminded today that this never landed and the LangRef is still wrong. Can you incorporate the explanation above about how this is used into the LangRef documentation?

arichardson requested changes to this revision.Nov 19 2022, 3:42 AM
arichardson added a subscriber: arichardson.

I was just looking at llvm.ptr.annotation and noticed that the LangRef did not match the actual arguments since D88645. Could you please fix this?

llvm/docs/LangRef.rst
19804
19844
Herald added a project: Restricted Project. · View Herald TranscriptNov 19 2022, 3:42 AM
lebedev.ri resigned from this revision.Jan 12 2023, 4:59 PM

This review may be stuck/dead, consider abandoning if no longer relevant.
Removing myself as reviewer in attempt to clean dashboard.