This is an archive of the discontinued LLVM Phabricator instance.

[X86] Fix isOffsetSuitableForCodeModel
AbandonedPublic

Authored by MaskRay on Jan 28 2020, 6:26 PM.

Details

Reviewers
None
Summary

If hasSymbolicDisplacement is false, there may still be a symbolic
displacement due to the order operands are matched.

X86DAGToDAGISel::matchAdd
  ...
  // Try again after commuting the operands.
  if (!matchAddressRecursively(Handle.getValue().getOperand(1), AM, Depth+1) && /// sets displacement
      !matchAddressRecursively(Handle.getValue().getOperand(0), AM, Depth+1))   /// sets symbol
    return false;

This can create a leaq symbol+disp(%rip), %rax instruction relocated by
R_X86_64_PC32. If symbol+disp-rip>=2**31 there will be a relocation overflow.

Diff Detail

Event Timeline

MaskRay created this revision.Jan 28 2020, 6:26 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 28 2020, 6:26 PM

Unit tests: pass. 62278 tests passed, 0 failed and 827 were skipped.

clang-tidy: pass.

clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

Instead of a new parameter is it possible to work something into the AddressingMode struct so that it gets restored when we restore from a backup AM?

Do you have a test case?

llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
213

This name doesn't match what's used in the definition of the function.

1594

Do we need to resync HasSymbolicDisp from the restored AM if one of the matchAddressRecursively calls failed the match but had modified the flag?

2098

Why is it called Force here?

craig.topper added inline comments.Jan 28 2020, 9:50 PM
llvm/lib/Target/X86/X86ISelDAGToDAG.cpp
1415

Without the test case, I can't be sure. But is the bug really just here where we don't check anything if the Offset is 0. But we still need to do the check if AM.Disp is already non-zero?

Instead of a new parameter is it possible to work something into the AddressingMode struct so that it gets restored when we restore from a backup AM?

Do you have a test case?

The bug was somewhat urgent and was breaking our release. @craig.topper So sorry, I went ahead and committed D73606.

I made more description there.

MaskRay abandoned this revision.Jan 28 2020, 11:39 PM