This is an archive of the discontinued LLVM Phabricator instance.

Explicitly pass type to cast load constant folding result
ClosedPublic

Authored by aeubanks on Apr 18 2021, 1:43 AM.

Details

Summary

Previously we would use the type of the pointee to determine what to
cast the result of constant folding a load. To aid with opaque pointer
types, we should explicitly pass the type of the load rather than
looking at pointee types.

ConstantFoldLoadThroughBitcast() converts the const prop'd value to the
proper load type (e.g. [1 x i32] -> i32). Instead of calling this in
every intermediate step like bitcasts, we only call this when we
actually see the global initializer value.

In some existing uses of this API, we don't know the exact type we're
loading from immediately (e.g. first we visit a bitcast, then we visit
the load using the bitcast). In those cases we have to manually call
ConstantFoldLoadThroughBitcast() when simplifying the load to make sure
that we cast to the proper type.

Diff Detail

Event Timeline

aeubanks created this revision.Apr 18 2021, 1:43 AM
aeubanks requested review of this revision.Apr 18 2021, 1:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2021, 1:43 AM
dblaikie accepted this revision.Apr 19 2021, 10:36 AM

Sounds good.

This doesn't have any behavior change? (probably add "[NFC]" to the patch title)

This revision is now accepted and ready to land.Apr 19 2021, 10:36 AM

I'm not 100% sure this is NFC, I think it's possible this might cause some behavior change with a very specific set of bitcasts, although it would be hard to reproduce since passes typically constant fold everything, not just one specific load instruction. But I built chrome with and without this change and it's the exact same size.

I'm not 100% sure this is NFC, I think it's possible this might cause some behavior change with a very specific set of bitcasts, although it would be hard to reproduce since passes typically constant fold everything, not just one specific load instruction. But I built chrome with and without this change and it's the exact same size.

Fair enough. I'm a little uncomfortable if there could be an actual change here, committing it without a test for that - but if it's unlikely to be practical to hand-craft a test in a reasonable amount of time, I'm OK with you going ahead with it, then. Maybe add some caveats to the commit message to explain why there isn't a test here, but that it also might not be NFC, uin case anyone comes looking to try to root cause a bug, etc.

I've updated the commit message to mention that.

This revision was landed with ongoing or failed builds.Apr 20 2021, 12:59 AM
This revision was automatically updated to reflect the committed changes.