This is an archive of the discontinued LLVM Phabricator instance.

[MemoryLocation] learn about ptr_provenance
AcceptedPublic

Authored by jeroen.dobbelaere on Aug 3 2021, 7:45 AM.

Details

Summary

Introduce a ptr_provenance member to MemoryLocation.

Note: in the full restrict patches, the ptr_provenance was tracked through the AAMDNodes. For this extraction of the feature, I feel that the MemoryLocation is a more logical place for it. (aka, the provenance is associated to a location, not to the Alias Analysis Metadata).

Diff Detail

Event Timeline

jeroen.dobbelaere requested review of this revision.Aug 3 2021, 7:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2021, 7:45 AM

As shown in https://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&branch=dobbelaj-snps/perf/ptr_provenance-20210803-03, it seems that tracking the ptr_provenance in the MemoryLocation results in a pretty big extra overhead.

Tracking it in the AAMDNodes as we do in the full restrict patches (See https://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&branch=dobbelaj-snps/perf/full_restrict-20200918 ; change f3d32e5da7 'looking through noalias intrinsics') seems to have a less severe impact..

  • Rebased
  • use llvm::hash_combine instead of xor for combining the different elements. This avoids hash clashes when ptr == ptr_provenance
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 7:03 AM

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

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)

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)

https://llvm-compile-time-tracker.com/?config=NewPM-O3&stat=instructions%3Au&remote=dobbelaj-snps&branch=dobbelaj-snps/perf/MemoryLocation-hashing-20221211-01 shows that most of the regression originates from using llvm::hash_combine instead of operator^ (fadd01d66c). A smaller part is added because of the memory usage and initialization of the extra pointer member. Including that extra pointer into the hash computation seems to have only minimal effect.

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

asbirlea accepted this revision.Jan 12 2023, 12:58 PM

In my opinion, this is fine.

This revision is now accepted and ready to land.Jan 12 2023, 12:58 PM