This is an archive of the discontinued LLVM Phabricator instance.

Avoid setting tbaa information on store of return type of call to inline assember
ClosedPublic

Authored by schittir on Dec 7 2021, 11:09 PM.

Details

Summary

In 32bit mode, attaching TBAA metadata to the store following the call to inline assembler results in describing the wrong type by making a fake lvalue(i.e., whatever the inline assembler happens to leave in EAX:EDX.) Even if inline assembler somehow describes the correct type, setting TBAA information on return type of call to inline assembler is likely not correct, since TBAA rules need not apply to inline assembler.

Diff Detail

Event Timeline

schittir created this revision.Dec 7 2021, 11:09 PM
schittir requested review of this revision.Dec 7 2021, 11:09 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 7 2021, 11:09 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Do you have a testcase ?

schittir updated this revision to Diff 392840.Dec 8 2021, 11:12 AM
schittir added a subscriber: mikerice.

Add test case
Fix formatting

Do you have a testcase ?

Thank you for the review. Please take a look at the new diff.

schittir retitled this revision from Avoid setting tbaa information on return type of call to inline assember to Avoid setting tbaa information on store of return type of call to inline assember.Dec 8 2021, 11:14 AM

When I try out the example on llvm-13, I get a 'omnipotent char' tbaa description. That should be ok in general. When I replace the 'float _Complex' with 'double', I do get the 'double' tbaa. That might be a better example for the testcase ?

schittir updated this revision to Diff 393381.Dec 9 2021, 11:28 PM

Updated test per Jeroen's suggestion

When I try out the example on llvm-13, I get a 'omnipotent char' tbaa description. That should be ok in general. When I replace the 'float _Complex' with 'double', I do get the 'double' tbaa. That might be a better example for the testcase ?

Good point. I updated the test with this suggestion. Thank you.

clang/lib/CodeGen/CodeGenFunction.h
2511

Looking at how a 'null tbaa'is produced in other places (grep for 'TBAAAccessInfo()', I would just do a 'TBAAAccessInfo()' here and omit the new ''returnNullTBAA' method.

clang/test/CodeGen/avoidTBAAonASMstore.cpp
7

Will this also work in release mode ? Maybe abstract away the %2 and %1.

schittir updated this revision to Diff 393642.Dec 10 2021, 5:48 PM
schittir marked an inline comment as done.
  1. Removed returnNullTBAA() method
  2. Add NO-TBAA check-prefix to the test
schittir marked an inline comment as done.Dec 10 2021, 5:49 PM

We're almost there. But the testcase is now not testing what it should be testing. Also the unused CHECK: must be adapted.

schittir updated this revision to Diff 393945.Dec 13 2021, 9:50 AM

Changing test's CHECK lines

schittir updated this revision to Diff 393948.Dec 13 2021, 9:54 AM

Fix test format

https://reviews.llvm.org/harbormaster/unit/view/1536685/
Test failure seems unrelated to this patch. Unable to reproduce locally.

schittir updated this revision to Diff 394173.Dec 14 2021, 12:56 AM

Rebasing patch to see if the test failure will go away.

clang/test/CodeGen/avoidTBAAonASMstore.cpp
4

Shouldn't this be STORE-LINE-LABEL: ... ?

schittir updated this revision to Diff 394176.Dec 14 2021, 1:17 AM

Change CHECK-LABEL to STORE-LINE-LABEL

schittir marked an inline comment as done.Dec 14 2021, 1:17 AM
This revision is now accepted and ready to land.Dec 14 2021, 8:57 AM
This revision was landed with ongoing or failed builds.Dec 14 2021, 5:45 PM
This revision was automatically updated to reflect the committed changes.

Hi, the new test is failing on our arm/aarch64 quick bots. These build only the respective backend so you might need to add a requires x86 target.

https://lab.llvm.org/buildbot/#/builders/171/builds/7189

/home/tcwg-buildbot/worker/clang-armv7-quick/llvm/clang/test/CodeGen/avoidTBAAonASMstore.cpp:5:3: error: MS-style inline assembly is not available: No available targets are compatible with triple "i386-unknown-linux-gnu"
  __asm { fnstcw word ptr[ControlWord]}
  ^
1 error generated.

I've gone ahead and added the REQUIRES myself.

I've gone ahead and added the REQUIRES myself.

Thank you, David!