This is an archive of the discontinued LLVM Phabricator instance.

[UnknownProvenance] Add LLVM-IR support for unknown_provenance
AcceptedPublic

Authored by jeroen.dobbelaere on Oct 5 2021, 8:06 AM.

Details

Summary

This adds the unknown_provenance LLVM-IR keyword, corresponding to the UnknownProvenance constant.

Diff Detail

Event Timeline

jeroen.dobbelaere requested review of this revision.Oct 5 2021, 8:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 5 2021, 8:06 AM

Added missing LLLexer support.

MatzeB added a subscriber: MatzeB.Nov 3 2021, 5:12 PM

Please document this in the LLVM language reference! I for one have trouble following the discussions (since I didn't have the time to read all the C/C++ reports yet)

Where is RFC or some high level document?

Please document this in the LLVM language reference! I for one have trouble following the discussions (since I didn't have the time to read all the C/C++ reports yet)

The langref update is in D104268

Where is RFC or some high level document?

The general Full Restrict RFC is referenced to in D68484 (Pointed to by D104268, which introduces the ptr_provenance operand and provides the langref update).

The unknown_provenance (UnknownProvenance) constant is being introduced as a clean way to indicate that a ptr_provenance is unknown.
In the original full restrict proposal, this role was served by using undef (UndefValue) as ptr_provenance operand.
For full restrict that was ok, but when we want to use ptr_provenance in a broader context having a special value results in a cleaner implementation without ambiguity.
(Especially if, at a later time, we want to make use of ptr_provenance in BasicAliasAnalysis, not just ScopedNoAliasAA).

Should there be a verifier change to ensure that it is *actually* only used in the provenance operand, and not as a pure pointer,
or can it be PHI'd/select'ed from multiple variants?

Should there be a verifier change to ensure that it is *actually* only used in the provenance operand, and not as a pure pointer,
or can it be PHI'd/select'ed from multiple variants?

Yes, that definitely makes sense.
It can be PHI'd, select'ed, cast'ed. But in the end, the usage must only show up in the provenance path of load,store,llvm.ptr.provenance.

I'll look into this in the coming days.

ormris removed a subscriber: ormris.Jan 24 2022, 11:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 6:57 AM

Should there be a verifier change to ensure that it is *actually* only used in the provenance operand, and not as a pure pointer,
or can it be PHI'd/select'ed from multiple variants?

I added the verifier in D128813

Test for the lexer/parser are missing. Positive and negative.

Test for the lexer/parser are missing. Positive and negative.

At this point I think it is hard to already introduce these tests: tests that trigger reading the unknown_provenance LLVM-IR constant are available in D104269 and D128813.
A test that triggers writing the LLVM-IR unknown_provenance constant is available in D104269 (and enabled in D104270)

jdoerfert accepted this revision.Oct 25 2022, 10:07 AM

To go in with the others only.

This revision is now accepted and ready to land.Oct 25 2022, 10:07 AM