Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

Rebased to: 8c7cfa357280dd93d33b10bbba0fe33797e27d63 (Feb 14, 2023)

In D69542#4046725, @nikic wrote:

Thanks for the rebase!

I tested the updated patch with rustc, but unfortunately didn't get very far again. The proc_macro build fails with verifier errors:
...
Here is the input IR (run under e.g. opt -O2): https://gist.github.com/nikic/fb9701235151e199fff0a23530808539

Hi @nikic, thanks for trying it out. I am able to reproduce the problem and was also able to produce a reduced version. I'll provide an update once I have a fix.

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Rebased to ef545ef62a833152d8975ff16333b57cc41befcc (Jan 9, 2023)

Hi Ralph,

In D69542#4010990, @RalfJung wrote:

Hm I cannot find the diff that the 2nd and 3rd comment refer to in https://reviews.llvm.org/D104268? Am I looking at the wrong thing? It refers to the new "Scoped NoAlias Related Intrinsics" section of the LangRef.

Ping - Anyone who can help reviewing this ?

@asbirlea do you think this is acceptable ? We can also keep the ugly xor and use that result with llvm::hash_combine to bring in the new Val.ptrProvenance.

In D107352#3986784, @jeroen.dobbelaere wrote:

In D107352#3957589, @asbirlea wrote:

Could you add updated compile-time impact measurements after the latest rebase?

I have rebased the patches and let the compile-time tracker look at it. Results can be found here: https://llvm-compile-time-tracker.com/?config=NewPM-O3&stat=instructions%3Au&remote=dobbelaj-snps&branch=dobbelaj-snps/perf/ptr_provenance-20221207-02
Compared to the (old) run with the huge effect on the speed, there is still some effect visible. (1e51b7f42b)

In D107352#3957589, @asbirlea wrote:

Could you add updated compile-time impact measurements after the latest rebase?

Hi Ralf, thanks for your feedback !

In D104270#3883808, @jdoerfert wrote:

Why do we add the boolean, isn't a nullptr/unknown provenance just as good?

In D69542#3932775, @vzakhari wrote:

Hi @jeroen.dobbelaere, can you please rebase the patch? I would like to try @llvm.noalias for Flang generated IR, but the patch would not apply cleanly. Thank you!

In D111160#3772453, @jdoerfert wrote:

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

LGTM

lgtm

In D111160#3139503, @lebedev.ri wrote:

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?

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

Rebased to ffe262a198a9f9030991df6d3ddd812e74fa3523

• Rebased
• Track ptr_provenance also during lowering (this was not working any more when ptr_provenance got moved outside of AAMetaData)

In D126956#3604978, @fhahn wrote:

Please take a look and revert the patch if the fix isn't trivial.

lgtm

In D107354#3495878, @jeroen.dobbelaere wrote:

In D107354#3494239, @Zoxc wrote:

Given that the provenance gets dropped in https://reviews.llvm.org/D107356, how does it end up in machine operands?

Good question. The provenance embedded in the MachineOperand here originates from the ptr_provenance operand in load/store instructions.
Your question does point out that https://reviews.llvm.org/D107356 (aka CodeGen/IntrinsicLowering) is too early if we want to track the more complex forms
of provenance after lowering.

In D107356#3495880, @jeroen.dobbelaere wrote:

NOTE: this should not be done here. The ptr_provenance Value in D107354 must still be able to see these intrinsics.

In D122205#3555266, @tstellar wrote:

@jeroen.dobbelaere What do you think about backporting this to the release/14.x branch?

In D111159#3498808, @deadalnix wrote:

Do you need help merging this?

NOTE: this should not be done here. The ptr_provenance Value in D107354 must still be able to see these intrinsics.

In D107354#3494239, @Zoxc wrote:

Given that the provenance gets dropped in https://reviews.llvm.org/D107356, how does it end up in machine operands?

In D69542#3465162, @D.Kharlamov wrote:

Hi. I tried to use your patch for my project. My main concern is AA in MachineScheduler.
I noticed what ptr_provenance info is not passed to CodeGen.
It could be fixed by adding it to MemoryMachineOperand constructor in SelectionDAGBuilder::visitLoad and SelectionDAGBuilder::visitStore.

Looks good. Thanks for documenting this !

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

Rebase to 49cb4fef02e635bf304906232214166c7531d753

In D122205#3399442, @steplong wrote:

In D122205#3399389, @jeroen.dobbelaere wrote:

Unfortunately, the context of this patch is not available :(

Whoops, should have explained the context. We were seeing GVN remove a load that had a TBAA that matched the 2nd store because GVN determined that it didn't match the TBAA on the memset that was created. The memset had the TBAA of the first store.

After looking at the full function and seeing how it is used: 'merge' is indeed the right operation to use here.

Unfortunately, the context of this patch is not available :(

Hi @hkao13 You happen to have some reduced testcases that show the problem ? Thanks !

LGTM. Thanks !

Sorry about not mentioning it with the previous part.

I checked the testcases for now and found some interesting effects. Can you comment on those ?