This is an archive of the discontinued LLVM Phabricator instance.

[X86] Alternative implementation of D73606 matchAdd: don't fold a large offset into a %rip relative address
ClosedPublic

Authored by craig.topper on Jan 29 2020, 12:44 AM.

Details

Summary

I might be wrong, but I think the main issue here is that we
earlied out of foldOffsetIntoAddress if Offset is 0. But if we
just found a symbolic displacement and AM.Disp became non-zero
earlier, we still need to validate that AM.Disp with the symbolic
displacement.

This passes fold-add-pcrel.ll.

Diff Detail

Event Timeline

craig.topper created this revision.Jan 29 2020, 12:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 29 2020, 12:44 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
MaskRay added a comment.EditedJan 29 2020, 3:15 PM

Thanks for the patch! Nice clean-up! I only get some nits.

This passes the test case from D73606.

Be a bit more explicit and just mention fold-add-pcrel.s

I am still wondering whether we can simplify %rip relative offset folding. Whether FIXME like below can be fixed:

// FIXME: JumpTable and ExternalSymbol address currently don't like
// displacements.  It isn't very important, but this should be fixed for
// consistency.
if (!(AM.ES || AM.MCSym) && AM.JT != -1)
  return true;
llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
1416

everying -> everything

int64_t Val = AM.Disp + Offset; can be placed immediately below the comment.

1588

commuting -> commutating

1589

clang-format will prefer Depth + 1

craig.topper edited the summary of this revision. (Show Details)

Address review comments

MaskRay accepted this revision.Jan 29 2020, 5:26 PM
This revision is now accepted and ready to land.Jan 29 2020, 5:26 PM
This revision was automatically updated to reflect the committed changes.