This is an archive of the discontinued LLVM Phabricator instance.

Support literal structs in mangled intrinsics.
AcceptedPublic

Authored by pgavlin on Nov 13 2015, 1:39 PM.

Details

Reviewers
reames
sanjoy
Summary

Literal structs are mangled as 'ls_' ( mangled fields) 's'. Mangling for structs is also changed to add a 's_' prefix and a 's' postfix to handle nested structs and struct names that may collide with other mangled types.

Diff Detail

Event Timeline

pgavlin updated this revision to Diff 40174.Nov 13 2015, 1:39 PM
pgavlin retitled this revision from to Support literal structs in mangled intrinsics. .
pgavlin updated this object.
pgavlin added reviewers: reames, sanjoy.
pgavlin added a subscriber: llvm-commits.

Expand overloaded-intrinsic-name.ll test to include an overload using a literal struct type and execute the new codepath?

pgavlin updated this revision to Diff 40412.Nov 17 2015, 10:59 AM

Expand overloaded-intrinsic-name.ll test to include an overload using a literal struct type and execute the new codepath?

Done.

majnemer added inline comments.
lib/IR/Function.cpp
492–493

Please consistently use braces.

pgavlin updated this revision to Diff 40418.Nov 17 2015, 11:57 AM

Addressed review feedback.

pgavlin marked an inline comment as done.Nov 18 2015, 10:26 AM

Ping: I think I've addressed all feedback.

@reames/@sanjoy, do you think you'll have a chance to take a look at this soon? This is hampering LLILC's ability to use statepoints with the SysV AMD64 ABI.

reames accepted this revision.Nov 24 2015, 2:08 PM
reames edited edge metadata.

The new literal struct naming rules seem fine, but the change in non-literal structs is not. Unless you have a strong motivation for it, I'd prefer to see that portion of the change reverted.

lib/IR/Function.cpp
493

I'm not sure the change in serialization is acceptable here. This will silently break previously valid code. Is there a reason why the nesting scheme needs to apply to non-literal structs? I think you can leave the old code in place for non-literal structures and just add the nesting for the new case.

test/CodeGen/Generic/overloaded-intrinsic-name.ll
47

This is the change I'm concerned about.

This revision is now accepted and ready to land.Nov 24 2015, 2:08 PM
pgavlin added inline comments.Nov 24 2015, 2:58 PM
lib/IR/Function.cpp
493

Consider the following:

%si64 = type { i64 }
%s = type { i64 }

; struct
define %si64* @test_struct(%si64* %v, %s* %w) gc "statepoint-example" {
       %tok = call i32 (i64, i32, %si64* ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_p0si64f(i64 0, i32 0, %si64* ()* @return_si64, i32 0, i32 0, i32 0, i32 0)
       ;%tok = call i32 (i64, i32, %s* (i64)*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_p0si64f(i64 0, i32 0, %s* (i64)* @return_s, i32 1, i32 0, i64 0, i32 0, i32 0)
       ret %si64* %v
}

declare %si64* @return_si64()
declare %s* @return_s(i64)

declare i32 @llvm.experimental.gc.statepoint.p0f_p0si64f(i64, i32, %si64* ()*, i32, i32, ...)
;declare i32 @llvm.experimental.gc.statepoint.p0f_p0si64f(i64, i32, %s* (i64)*, i32, i32, ...)

The mangled names of the two signatures for the statepoint intrinsic collide due to the names of the structs and the parameter types involved. The proposed scheme avoids this collision, as the names become:

declare i32 @llvm.experimental.gc.statepoint.p0f_p0s_si64sf(i64, i32, %si64* ()*, i32, i32, ...)
declare i32 @llvm.experimental.gc.statepoint.p0f_p0s_ssi64f(i64, i32, %s* (i64)*, i32, i32, ...)
reames added a comment.Jan 6 2016, 6:57 PM

LGTM. The explanation on the non-literal form makes sense. I'm still not happy about the break in the naming scheme, but I don't have a better option either.

Just for the record, this really should have been two patches. One was a minor enhancement, the other was a subtle change which required careful thought. Please make sure when you land this that you call out the issue here so that it's obvious to readers.

sanjoy resigned from this revision.Jan 29 2022, 5:25 PM