This is an archive of the discontinued LLVM Phabricator instance.

[X86ISelLowering] permit BlockAddressSDNode "i" constraints for PIC
ClosedPublic

Authored by nickdesaulniers on Feb 15 2022, 4:22 PM.

Details

Summary

When building 32b x86 code as PIC, the existing handling of "i"
constraints is conservative since generally we have to go through the
GOT to find references to functions.

But generally, BlockAddresses from C code refer to the Function in the
current TU. Permit BlockAddresses to be used with the "i" constraint
for those cases.

I regressed this in
commit 4edb9983cb8c ("[SelectionDAG] treat X constrained labels as i for asm")

Fixes: https://github.com/llvm/llvm-project/issues/53868

Diff Detail

Event Timeline

nickdesaulniers requested review of this revision.Feb 15 2022, 4:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 15 2022, 4:22 PM
nickdesaulniers edited the summary of this revision. (Show Details)
  • manually format like a peasant
llvm/lib/Target/X86/X86ISelLowering.cpp
54796

interesting, the code formatter didn't run on this file. Probably because it's too big.

Looks like the Subtarget.isPICStyleGOT() || Subtarget.isPICStyleStubPIC() check was added in

commit 5ad5226c58c8 ("Disallow matching "i" constraint to symbol addresses when address requires a register or secondary load to compute (most PIC modes). This improves "g" constraint handling. 8015842.")

I don't think you need to check that the blockaddress refers to the current function. A blockaddress always refers to the version of the function in the current file (similar to the way an alias works). So the address is always going to be valid; you never have to go through a GOT or anything like that.

I think there are other issues with this code; it isn't handling all the patterns that it should. See immediate handling in TargetLowering::LowerAsmOperandForConstraint.

nickdesaulniers edited the summary of this revision. (Show Details)
  • don't check blockaddress Function, as per @efriedma. Merge tests

I think there are other issues with this code; it isn't handling all the patterns that it should. See immediate handling in TargetLowering::LowerAsmOperandForConstraint.

Luckily, the target specific overrides defer to the base classes method (by explicitly calling TargetLowering::LowerAsmOperandForConstraint from X86TargetLowering::LowerAsmOperandForConstraint. It's below the fold of what phab shows, but it's just a few lines down from my hunk if you expand the view in phab.

A blockaddress always refers to the version of the function in the current file (similar to the way an alias works).

I'm not sure that holds under LTO. Otherwise I don't think we'd have bugs like: https://github.com/llvm/llvm-project/issues/52787.

A blockaddress always refers to the version of the function in the current file (similar to the way an alias works).

I'm not sure that holds under LTO. Otherwise I don't think we'd have bugs like: https://github.com/llvm/llvm-project/issues/52787.

It has to hold, or else everything just explodes. blockaddresses aren't in the public symbol table of an object file.

This does make LTO a bit more complicated, but not impossible. (e.g. ThinLTO can't import functions from other bitcode files if they refer to a blockaddress.)

This revision is now accepted and ready to land.Feb 16 2022, 3:00 PM
nickdesaulniers added a comment.EditedFeb 16 2022, 3:05 PM

(I plan on requesting this be backported to clang-14 to fix https://github.com/llvm/llvm-project/issues/53868; I'm going to be on vacation next week so I'm going to land this + request backport ASAP).

Thanks for the review + feedback.

MaskRay accepted this revision.Feb 16 2022, 4:25 PM

Consider placing the test in an existing ${0:l} test, e.g. asm-block-labels.ll

  • move unit tests into existing llvm/test/CodeGen/X86/inline-asm-pic.ll

Consider placing the test in an existing ${0:l} test, e.g. asm-block-labels.ll

llvm/test/CodeGen/X86/inline-asm-pic.ll seemed more appropriate (-m32 && -fPIC).

Thanks for the review!

This revision was landed with ongoing or failed builds.Feb 17 2022, 10:55 AM
This revision was automatically updated to reflect the committed changes.