This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Mark pointers to constant address space as invariant
Needs ReviewPublic

Authored by yaxunl on Mar 1 2020, 7:05 AM.

Details

Summary

OpenCL constant address space is immutable, therefore pointers to constant address space can
be marked with llvm.invariant.start permanently.

This should allow more optimization opportunities in LLVM passes.

Diff Detail

Event Timeline

yaxunl created this revision.Mar 1 2020, 7:05 AM
rjmccall added inline comments.Mar 1 2020, 9:48 PM
clang/lib/CodeGen/CGDeclCXX.cpp
169–171

I know this is a pre-existing code pattern, but there's an overload of CreateCall that just takes two arguments directly; please switch the code to use that.

170

This check is already done by CreateBitCast.

clang/lib/CodeGen/CGExpr.cpp
1255

This is not the way to do this, but fortunately it's unnecessary anyway. You can just put the invariant-load metadata on any loads from the constant address space in the functions called by EmitLoadOfLValue.

hliao added a subscriber: hliao.Mar 2 2020, 8:40 AM

invariant checking already takes account of loading from constant address space or memory (AA::pointsToConstantMemory), that's almost equivalent to adding invariant attributes. Why do we mark these constant loads with additional attributes?

yaxunl added a comment.Mar 2 2020, 8:57 AM

invariant checking already takes account of loading from constant address space or memory (AA::pointsToConstantMemory), that's almost equivalent to adding invariant attributes. Why do we mark these constant loads with additional attributes?

I got this request from Matt. He wants a consistent representation for invariant load, not relying on alias analysis.

invariant checking already takes account of loading from constant address space or memory (AA::pointsToConstantMemory), that's almost equivalent to adding invariant attributes. Why do we mark these constant loads with additional attributes?

If alias analysis already knows that all memory in the constant address space is immutable, I agree that should be sufficient, at least on targets where the constant address space is actually a different address space in LLVM IR. If it only knows that when it can resolve an access down to a specific constant global variable, this patch is still providing value because it applies even for accesses through a pointer.

yaxunl added a comment.Mar 2 2020, 9:35 AM

invariant checking already takes account of loading from constant address space or memory (AA::pointsToConstantMemory), that's almost equivalent to adding invariant attributes. Why do we mark these constant loads with additional attributes?

If alias analysis already knows that all memory in the constant address space is immutable, I agree that should be sufficient, at least on targets where the constant address space is actually a different address space in LLVM IR. If it only knows that when it can resolve an access down to a specific constant global variable, this patch is still providing value because it applies even for accesses through a pointer.

There is plan for amdgcn target to drop constant address space in IR and use global address space instead.

Also, currently there are targets (e.g. x86_64) supporting OpenCL which does not have constant address space in IR.

invariant checking already takes account of loading from constant address space or memory (AA::pointsToConstantMemory), that's almost equivalent to adding invariant attributes. Why do we mark these constant loads with additional attributes?

If alias analysis already knows that all memory in the constant address space is immutable, I agree that should be sufficient, at least on targets where the constant address space is actually a different address space in LLVM IR. If it only knows that when it can resolve an access down to a specific constant global variable, this patch is still providing value because it applies even for accesses through a pointer.

There is plan for amdgcn target to drop constant address space in IR and use global address space instead.

Also, currently there are targets (e.g. x86_64) supporting OpenCL which does not have constant address space in IR.

Okay, then I have no problem taking a patch for this into IRGen. But I think it should be fine to do this by adding the invariant-load metadata when loading from an l-value instead of injecting invariant-groups into l-value emission.

Okay, then I have no problem taking a patch for this into IRGen. But I think it should be fine to do this by adding the invariant-load metadata when loading from an l-value instead of injecting invariant-groups into l-value emission.

The pointer to constant may be casted to a generic pointer then loaded. If we only mark load from pointer to constant, we loses information.

yaxunl updated this revision to Diff 247688.Mar 2 2020, 10:31 AM
yaxunl marked 2 inline comments as done.

revised by John's comments.

Okay, then I have no problem taking a patch for this into IRGen. But I think it should be fine to do this by adding the invariant-load metadata when loading from an l-value instead of injecting invariant-groups into l-value emission.

The pointer to constant may be casted to a generic pointer then loaded. If we only mark load from pointer to constant, we loses information.

A lot of those conversions don't go through EmitLValue.

Doing this at this level in EmitLValue both complicates the code and will introduce a lot of redundant intrinsic calls. If you need to do it, you should do it at the root where a pointer is being turned into an LValue.