This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Remove a provenance changing gep transformation
AbandonedPublic

Authored by nagisa on Mar 6 2021, 11:13 AM.

Diff Detail

Event Timeline

nagisa created this revision.Mar 6 2021, 11:13 AM
nagisa requested review of this revision.Mar 6 2021, 11:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 6 2021, 11:13 AM

I'm quite surprised this change didn't affect any pre-existing tests. It however, is sufficient to resolve one of a fairly easily hit mis-compiles in Rust.

(Side note: my understanding of this area of code is fairly limited, looking forward to learning something out of this)

lebedev.ri added a subscriber: lebedev.ri.

Looks good to me.

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
2150–2151

This whole transform needs to go away, feel free to submit that as a preparatory patch.

nagisa retitled this revision from [InstCombine] Do not apply provenance losing operations on GEP to [InstCombine] Do not apply provenance losing transformations to GEP.Mar 6 2021, 11:30 AM
nagisa updated this revision to Diff 328803.Mar 6 2021, 12:05 PM

restore a deleted comment

nikic added a comment.Mar 6 2021, 12:22 PM

The (in)correctness of this transform isn't really related to inbounds, see https://alive2.llvm.org/ce/z/Pr8daF. Actually, after @lebedev.ri's commit this code is now in sync with InstSimplify (both fold the ptrtoint-ptrtoint case, but not the 0-ptrtoint case).

The remaining fold (both here and in InstSimplify) is only valid if both pointers have the same provenance, i.e. getUnderlyingObject() is the same. I don't know what the fallout of enforcing that would be.

nagisa abandoned this revision.Mar 6 2021, 12:22 PM

The issue this was trying to solve was effectively resolved by rG2ad1f5eb1a47: [InstCombine] Don't canonicalize (gep i8* X, -(ptrtoint Y)) as (inttoptr…. I'm happy to abandon this, because the change to the other transformation is of questionable correctness anyway.

Thanks @lebedev.ri!

lebedev.ri edited the summary of this revision. (Show Details)Mar 6 2021, 12:39 PM
nagisa updated this revision to Diff 328816.Mar 6 2021, 1:51 PM

Pivot to removing the provenance losing transformation

nagisa retitled this revision from [InstCombine] Do not apply provenance losing transformations to GEP to [InstCombine] Remove a provenance changing gep transformation.Mar 6 2021, 1:52 PM
nagisa edited the summary of this revision. (Show Details)Mar 6 2021, 1:54 PM

The remaining fold (both here and in InstSimplify) is only valid if both pointers have the same provenance, i.e. getUnderlyingObject() is the same.

That's a good point, this fold should be somewhat good iff we can prove that it doesn't miscompile.

I don't know what the fallout of enforcing that would be.

Ack.

nagisa abandoned this revision.Mar 14 2021, 2:41 PM