This is an archive of the discontinued LLVM Phabricator instance.

[bugpoint] Also replace declarations with null.
AbandonedPublic

Authored by fhahn on Feb 15 2020, 2:10 PM.

Details

Summary

Unless I am missing something, we can also replace calls to declarations
with null, similar to the way we handle regular functions. This helps to
reduce a few more cases and also reduces the number of globals in the
module we are working on.

Diff Detail

Event Timeline

fhahn created this revision.Feb 15 2020, 2:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2020, 2:10 PM
reames requested changes to this revision.Feb 25 2020, 9:29 AM

Calling null is (I think) full out UB. This may be a more hostile reduction strategy than is warranted. It's likely to result in extremely unstable reductions.

An alternative would be to pick a canonical callee (non-null declaration) and map all calls of a given signature to the same decl.

Also, I'm not opposed to this version if you really want, just pointing out a possible downside.

This revision now requires changes to proceed.Feb 25 2020, 9:29 AM
fhahn planned changes to this revision.Feb 25 2020, 1:23 PM

Calling null is (I think) full out UB. This may be a more hostile reduction strategy than is warranted. It's likely to result in extremely unstable reductions.

An alternative would be to pick a canonical callee (non-null declaration) and map all calls of a given signature to the same decl.

My original intention with this patch was to just extend the existing behavior to declarations as well, but I agree using null is not ideal. I'll give your suggestion a try!

Calling null is (I think) full out UB. This may be a more hostile reduction strategy than is warranted. It's likely to result in extremely unstable reductions.

An alternative would be to pick a canonical callee (non-null declaration) and map all calls of a given signature to the same decl.

My original intention with this patch was to just extend the existing behavior to declarations as well, but I agree using null is not ideal. I'll give your suggestion a try!

I possibly didn't read far enough. Are you saying we will replace the target of a call to a defined function w/null, but not for a call to a declaration? If so, then yes, simply being consistent is better than nothing. If that's the case, LGTM. :)

Calling null is (I think) full out UB. This may be a more hostile reduction strategy than is warranted. It's likely to result in extremely unstable reductions.

An alternative would be to pick a canonical callee (non-null declaration) and map all calls of a given signature to the same decl.

My original intention with this patch was to just extend the existing behavior to declarations as well, but I agree using null is not ideal. I'll give your suggestion a try!

I possibly didn't read far enough. Are you saying we will replace the target of a call to a defined function w/null, but not for a call to a declaration? If so, then yes, simply being consistent is better than nothing. If that's the case, LGTM. :)

Yes that's the case at the moment IIUC. This patch should just extend the existing behavior to also include declarations.

fhahn abandoned this revision.Nov 27 2021, 8:15 AM

Bugpoint is loosing relevance, I won't be able to follow up on this anytime soon.