This is an archive of the discontinued LLVM Phabricator instance.

[clang-repl] Allow Interpreter::getSymbolAddress to take a mangled name.
ClosedPublic

Authored by v.g.vassilev on Oct 27 2021, 1:56 PM.

Details

Diff Detail

Event Timeline

v.g.vassilev created this revision.Oct 27 2021, 1:56 PM
v.g.vassilev requested review of this revision.Oct 27 2021, 1:56 PM
rsmith added inline comments.Oct 27 2021, 2:45 PM
clang/include/clang/Interpreter/Interpreter.h
84

I find this flag name to be very confusing, given what "mangling" usually means within Clang. I think IsMangled = false means "this is a symbol name of the same kind that Clang would emit in IR", and IsMangled = true means "this is a symbol name of the same kind that would appear in an object file's symbol table" -- and the former is a mangled name in the sense in which the term is used in Clang.

Perhaps enum { IRName, LinkerName } instead of a bool flag would be clearer? But I'm not sure whether this flag is motivated given that your test case below wants / is testing the IsMangled = false behavior.

I wonder if a better interface here generally would be:

llvm::Expected<llvm::JITTargetAddress> getSymbolAddress(GlobalDecl GD) const;

... which could internally form the proper symbol name for the given GlobalDecl (or perhaps reuse CodeGen's decl -> mangling map rather than redoing the name mangling step).

clang/unittests/Interpreter/InterpreterTest.cpp
131–138

This function produces names that are not mangled in the sense that getSymbolAddress's IsMangled = true means. I would expect this test to fail on MacOS for that reason.

v.g.vassilev marked 2 inline comments as done.

Address comments

rsmith accepted this revision.Nov 9 2021, 2:50 PM
rsmith added inline comments.
clang/include/clang/Interpreter/Interpreter.h
72

Add a space before \returns please (here and below).

clang/unittests/Interpreter/IncrementalProcessingTest.cpp
20 ↗(On Diff #382939)

Given that this file is unchanged, do we need the new includes?

clang/unittests/Interpreter/InterpreterTest.cpp
166

Use EXPECT_EQ and EXPECT_NE as appropriate.

214

EXPECT_TRUE on an integer seems surprising.

This revision is now accepted and ready to land.Nov 9 2021, 2:50 PM
v.g.vassilev marked 4 inline comments as done.

Address comments and fix the windows bot failure.

v.g.vassilev added inline comments.Nov 10 2021, 2:24 AM
clang/unittests/Interpreter/IncrementalProcessingTest.cpp
20 ↗(On Diff #382939)

A leftover from some other experiments. Thanks!

There is no information in this patch as to why the changes are needed or useful; please use a more descriptive summary next time.

clang/unittests/Interpreter/InterpreterTest.cpp
205–207

FWIW, Intel's internal testing is hitting crashes with this test. With -fno-delayed-template-parsing enabled, we get a failed assertion:

Assertion failed: OffsetBytes <= AllocationSize && "Offset out of bounds!", file d:\iusers\ayrivera\dev-xmain-web\llvm\l
lvm\lib\executionengine\runtimedyld\RuntimeDyldImpl.h, line 90

and when we enable the delayed template parsing, we get a different assertion:

Assertion failed: DC->getLexicalParent() == CurContext && "The next DeclContext should be lexically contained in the current one.", file D:/iusers/ayrivera/dev-xmain-web/llvm/clang/lib/Sema/SemaDecl.cpp, line 1305

I think this FIXME either needs to be addressed or the patch reverted until this is addressed.

237–240

This test is broken for some of our internal build bots at Intel. I think something suspicious is going on here, but I'm not certain of the intent behind the test, so I'm not certain the best way to fix it. The behavior of the test is that on an x86 Windows machine, sometimes this particular test fails:

[ RUN ] IncrementalProcessing.InstantiateTemplate^M
unknown file: error: SEH exception with code 0x3221225477 thrown in the test body.^M
[ FAILED ] IncrementalProcessing.InstantiateTemplate (35 ms)^M

but it's not a consistent failure (seems to happen about one out of every three runs).

callme is a templated member function of B but here we're trying to call it like it's a free function. That's... not good. We could either make callme a static member function so that it can be called in this manner, or we could try to come up with a magic incantation to call it as a PMF.

Can you investigate, @v.g.vassilev? If it is going to take considerable time to resolve, it might be worth reverting temporarily. Thanks!

erichkeane added inline comments.
clang/unittests/Interpreter/InterpreterTest.cpp
237–240

To be perhaps succinct, the problem is calling Pointer-to-member-function as a free-function. The cast on line 239 is completely invalid, and can't be done in C++ code itself without UB.

We believe this shows up on x86 in particular since there is ALSO a calling-convention mismatch here, but this cast to TemplateSpecFn seems completely invalid to me.

aaron.ballman added inline comments.Nov 30 2021, 9:01 AM
clang/unittests/Interpreter/InterpreterTest.cpp
205–207

Ignore this -- this comment was saved in my Phab drafts from an earlier investigation and I managed to not delete it when sending my other comment (below). Oops!

v.g.vassilev added inline comments.Nov 30 2021, 12:53 PM
clang/unittests/Interpreter/InterpreterTest.cpp
237–240

Thanks for the ping, @aaron.ballman. Does making the function static fixes it? If it does, please go ahead and commit the fix otherwise I can do it in 12 hours.

If it does not fix it, could you share the bot logs or at least the cmake configure line and the platform?

eandrews added inline comments.
clang/unittests/Interpreter/InterpreterTest.cpp
237–240
v.g.vassilev added inline comments.Dec 1 2021, 5:33 AM
clang/unittests/Interpreter/InterpreterTest.cpp
237–240

Thanks!