-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[LICM] Support hoisting of non-argmemonly readonly calls #144497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The code checking whether a readonly call is safe to hoist is currently limited to only argmemonly calls. However, the actual implementation of does not depend on this in anyway. It either does an MSSA clobber walk on the memory access (which will take all locations accessed by the call into account), or it will look at all MemoryDefs in an entirely location-independent manner. The current restriction dates back to the time when LICM still supported AST, in which case this code *did* reason about the individual pointer arguments.
| declare void @may_throw() | ||
|
|
||
| declare i32 @pure_computation() nounwind argmemonly readonly willreturn | ||
| declare i32 @pure_computation() nounwind willreturn memory(none) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
argmemonly for a function without arguments is memory(none). Not LICM's job to figure that out...
preames
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
fhahn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
|
Hi @nikic I ran into a crash that I could bisect back to this patch. crashes in LICM with It's the cast below that fails: |
|
@mikaelholmen Thanks for the report. This should be fixed by 5753ee2 and #154289 would avoid the situation in the first place. |
Thanks! |
If FunctionAttrs infers additional attributes on a function, it also invalidates analysis on callers of that function. The way it does this right now limits this to calls with matching signature. However, the function attributes will also be used when the signatures do not match. Use getCalledOperand() to avoid a signature check. This is not a correctness fix, just improves analysis quality. I noticed this due to #144497 (comment), where LICM ends up with a stale MemoryDef that could be a MemoryUse (which is a bug in LICM, but still non-optimal).
…re (#154289) If FunctionAttrs infers additional attributes on a function, it also invalidates analysis on callers of that function. The way it does this right now limits this to calls with matching signature. However, the function attributes will also be used when the signatures do not match. Use getCalledOperand() to avoid a signature check. This is not a correctness fix, just improves analysis quality. I noticed this due to llvm/llvm-project#144497 (comment), where LICM ends up with a stale MemoryDef that could be a MemoryUse (which is a bug in LICM, but still non-optimal).
The code checking whether a readonly call is safe to hoist is
currently limited to only argmemonly calls. However, the actual
implementation does not depend on this in any way. It either
does an MSSA clobber walk on the memory access (which will take
all locations accessed by the call into account), or it will
look at all MemoryDefs in an entirely location-independent manner.
The current restriction dates back to the time when LICM still
supported AST, in which case this code did reason about the
individual pointer arguments.