This is an archive of the discontinued LLVM Phabricator instance.

[LoopIdiom] Merge TBAA of adjacent stores when creating memset
ClosedPublic

Authored by steplong on Mar 21 2022, 8:10 PM.

Details

Summary

Factor in the TBAA of adjacent stores instead of just the head store when merging stores into a memset. We were seeing GVN remove a load that had a TBAA that matched the 2nd store because GVN determined it didn't match the TBAA of the memset. The memset had the TBAA of only the first store.

i.e. Loading the field pi_ of shared_count after memset to create an array of shared_ptr

template<class T>
class shared_ptr {
  T *p;
  shared_count refcount;
};

class shared_count {
  sp_counted_base *pi_;
};

Diff Detail

Event Timeline

steplong created this revision.Mar 21 2022, 8:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 21 2022, 8:10 PM
steplong requested review of this revision.Mar 21 2022, 8:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 21 2022, 8:10 PM
jeroen.dobbelaere requested changes to this revision.Mar 22 2022, 6:25 AM

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

I think 'merge' is not the right thing to do. (https://github.com/llvm/llvm-project/blob/555df030121aeaaf33b1a89489960a77ef94d472/llvm/include/llvm/IR/Metadata.h#L732)
Probably 'concat' is.

This revision now requires changes to proceed.Mar 22 2022, 6:25 AM

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

This revision is now accepted and ready to land.Mar 22 2022, 6:36 AM

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.

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.

That is also handy to have as extra information, and should be added to the description.

But I was aiming for the the context of the full file instead of just the changes:

`git diff HEAD~1 -U999999 > mypatch.patch`

(see https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface)

Thanks,

Jeroen

steplong updated this revision to Diff 417285.Mar 22 2022, 7:06 AM
steplong edited the summary of this revision. (Show Details)
steplong edited the summary of this revision. (Show Details)Mar 22 2022, 7:08 AM

It seems some of the x64 debian tests timed out. I'm not sure how to rerun them

It seems some of the x64 debian tests timed out. I'm not sure how to rerun them

I don't think there's any way to rerun those tests... but you don't need to if the failure is unrelated.

CC'ing a few people for the RISCV test timeouts, so they're aware; maybe we can fix the tests to make them less likely to time out.

This revision was landed with ongoing or failed builds.Mar 30 2022, 4:55 PM
This revision was automatically updated to reflect the committed changes.

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

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

I think that makes sense.