This is an archive of the discontinued LLVM Phabricator instance.

[AutoUpgrade] Take unnamed types into account.
AbandonedPublic

Authored by jeroen.dobbelaere on Mar 22 2021, 3:52 AM.

Details

Summary

Ensure that we provide access to the Module when checking if a rename of an intrinsic is necessary.

This fixes the issue that was detected by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32288
(as mentioned by @fhahn), after committing D91250.

Diff Detail

Event Timeline

jeroen.dobbelaere requested review of this revision.Mar 22 2021, 3:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2021, 3:52 AM
jeroen.dobbelaere edited the summary of this revision. (Show Details)Mar 22 2021, 3:52 AM
fhahn added a comment.Mar 22 2021, 4:15 AM

Is there a way to ensure all call sites that may need to handle opaque pointers pass the module? can we add an assertion ensuring the module is passed if the intrinsic takes overloaded pointer types?

Is there a way to ensure all call sites that may need to handle opaque pointers pass the module? can we add an assertion ensuring the module is passed if the intrinsic takes overloaded pointer types?

The easiest way is to always pass the Module when a list of types is provided. But that is not a guarantee that the Module pointer will ever be needed for that specific intrinsic.

We could add an extra assertion that triggers when a pointer type is provided, but no Module is given. But also here, there will be false positives. (Intrinsics that can get a pointer, but not a pointer involving an unnamed type.)
I tried this in out, and got extra failures because of prefetch, masked_load, masked_store, masked_gather, masked_scatter. Can these intrinsics use pointers that involve unnamed types ?

Note: There might also be an issue with LLVMIntrinsicCopyOverloadedName, which does not have a Module parameter. As long as no unnamed types are used, that interface is fine, but it does not support unnamed types.

fhahn added a comment.Mar 22 2021, 8:49 AM

Is there a way to ensure all call sites that may need to handle opaque pointers pass the module? can we add an assertion ensuring the module is passed if the intrinsic takes overloaded pointer types?

The easiest way is to always pass the Module when a list of types is provided. But that is not a guarantee that the Module pointer will ever be needed for that specific intrinsic.

How many places would need to be updated? It sounds like there's no nice solution (automatically catch cases that really need the module), but it also seems brittle to have Intrinsic::getName crash in various places because of missing Module arguments.

We could add an extra assertion that triggers when a pointer type is provided, but no Module is given. But also here, there will be false positives. (Intrinsics that can get a pointer, but not a pointer involving an unnamed type.)
I tried this in out, and got extra failures because of prefetch, masked_load, masked_store, masked_gather, masked_scatter. Can these intrinsics use pointers that involve unnamed types ?

llvm.prefetch can be used with opaque types (https://godbolt.org/z/xnjx5b99Y), the other cannot be used with opaque pointers I think, because they also take vector arguments and opaque types cannot be used as vector element types.

Note: There might also be an issue with LLVMIntrinsicCopyOverloadedName, which does not have a Module parameter. As long as no unnamed types are used, that interface is fine, but it does not support unnamed types.

Ok it sounds like we also need a fix to the C api?

How many places would need to be updated? It sounds like there's no nice solution (automatically catch cases that really need the module), but it also seems brittle to have Intrinsic::getName crash in various places because of missing Module arguments.

It's not too much. We better then always require the Module parameter whenever types are provided.

[..]

Note: There might also be an issue with LLVMIntrinsicCopyOverloadedName, which does not have a Module parameter. As long as no unnamed types are used, that interface is fine, but it does not support unnamed types.

Ok it sounds like we also need a fix to the C api?

If we want to support the unnamed types, yes. Can we just require/add an extra Module argument ? Are there any rules for backwards compatibility for the C api ?

jeroen.dobbelaere abandoned this revision.Mar 29 2021, 2:19 AM

Dropping in favor of D99173.