This is an archive of the discontinued LLVM Phabricator instance.

[clang][Interp] Implement bool and nullptr literal expressions
ClosedPublic

Authored by tbaeder on Aug 15 2022, 11:36 PM.

Details

Summary

This is split out from https://reviews.llvm.org/D131888

As a start, implement handling of boolean and nullptr expressions. The patch includes a bug fix to readArg() advance the code pointer and a few other small changes I did while looking at the code. I can pull those out as well but I don't want to open too many review tickets.

Diff Detail

Event Timeline

tbaeder created this revision.Aug 15 2022, 11:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2022, 11:36 PM
tbaeder requested review of this revision.Aug 15 2022, 11:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 15 2022, 11:36 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
erichkeane added inline comments.Aug 17 2022, 6:23 AM
clang/lib/AST/Interp/Disasm.cpp
26

Are you sure this isn't intentional that this is passed by value? With a name like CodePtr, it certainly SOUNDS like it means to be passed by value.

clang/lib/AST/Interp/Function.h
69

is this an unrelated NFC change? In the future, please keep this out of patches that do stuff.

clang/lib/AST/Interp/Source.h
64

Ah, this DOES just wrap a pointer, passing by value is likely the right idea here.

clang/test/AST/Interp/literals.cpp
14

can you also do a 'getNullptr'? Also, a static-assert for all 3 of the functions as well.

tbaeder added inline comments.Aug 17 2022, 7:50 AM
clang/lib/AST/Interp/Disasm.cpp
26

CodePtr::read() advances the pointer that CodePtr wraps , so copying just to call read() on it makes little sense. E.g. in https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/Interp/Interp.cpp#L401-L412, ReadArg must advance the CodePtr, otherwise two consecutive ReadArg calls will read the same thing.

clang/lib/AST/Interp/Function.h
69

Okay.

clang/test/AST/Interp/literals.cpp
14

I can do a getNull(), but I can't call any of the functions yet, function calls aren't implemented yet.

tbaeder updated this revision to Diff 453284.Aug 17 2022, 7:51 AM
tbaeder retitled this revision from [clang][Inter[ Implement bool and nullptr literal expressions to [clang][Interp] Implement bool and nullptr literal expressions.
erichkeane added inline comments.Aug 17 2022, 7:54 AM
clang/lib/AST/Interp/Disasm.cpp
26

my point is; With a struct this small, the 'copy' is cheaper than a pass-by-ref. However, if the pass-by-value causes the ReadArg to read the same thing, why was this not a problem before? More importantly, what in this patch makes this change necessary?

clang/test/AST/Interp/literals.cpp
14

ah, thanks for that clarificaiton. When doing the function-calls, please see if you can add that here as well.

tbaeder marked 3 inline comments as done.Aug 17 2022, 8:15 AM
tbaeder added inline comments.
clang/lib/AST/Interp/Disasm.cpp
26

Nothing in this patch, if you e.g. take this code:

constexpr int func() { return 5; }

and run it with clang++ -std=c++20 -fexperimental-new-constant-interpreter, the constant interpreter runs into an assertion while evaluating the bytecode for that function. Switching ReadArg to take the codeptr by reference fixes that. So I could probably postpone the change to a later patch but it's one of the first problems I ran into while working on the codebase.

erichkeane accepted this revision.Aug 17 2022, 8:21 AM
erichkeane added inline comments.
clang/lib/AST/Interp/Disasm.cpp
26

I see, thanks for the explanation. I think it is fine now, it just wasn't clear that this was covered by a test or necessary.

This revision is now accepted and ready to land.Aug 17 2022, 8:21 AM
aaron.ballman accepted this revision.Aug 17 2022, 8:52 AM

LGTM as well; should we add a release note for this? I suspect not because it's improving an experimental feature that's not really ready for prime time yet, but I don't know how others feel.

LGTM as well; should we add a release note for this? I suspect not because it's improving an experimental feature that's not really ready for prime time yet, but I don't know how others feel.

That was my thought on it, though thinking further, I wonder if there is value to it to show 'signs of life' in the release notes?

LGTM as well; should we add a release note for this? I suspect not because it's improving an experimental feature that's not really ready for prime time yet, but I don't know how others feel.

That was my thought on it, though thinking further, I wonder if there is value to it to show 'signs of life' in the release notes?

@tbaeder -- do you have plans to continue to add support to the experimental constant expression evaluator?

If this is code that we have people actively working on with plans to bring it to completion, then I think showing signs of life in the release notes is a good idea. If we don't have anyone who is planning to bring this through to completion, I think we should seriously considering pulling it out of the tree rather than trying to maintain parallel constant expression evaluators. (We wouldn't be pulling it out of the tree because we don't like the design, so if someone wanted to resurrect it in the future because they planned to complete it, we'd gladly welcome it.)

LGTM as well; should we add a release note for this? I suspect not because it's improving an experimental feature that's not really ready for prime time yet, but I don't know how others feel.

That was my thought on it, though thinking further, I wonder if there is value to it to show 'signs of life' in the release notes?

@tbaeder -- do you have plans to continue to add support to the experimental constant expression evaluator?

If this is code that we have people actively working on with plans to bring it to completion, then I think showing signs of life in the release notes is a good idea. If we don't have anyone who is planning to bring this through to completion, I think we should seriously considering pulling it out of the tree rather than trying to maintain parallel constant expression evaluators. (We wouldn't be pulling it out of the tree because we don't like the design, so if someone wanted to resurrect it in the future because they planned to complete it, we'd gladly welcome it.)

I certainly plan to keep working on it. I have a few more such patches locally that you'll have pleasure reviewing I'm sure :). It think adding a small changelog note is fine of course.

LGTM as well; should we add a release note for this? I suspect not because it's improving an experimental feature that's not really ready for prime time yet, but I don't know how others feel.

That was my thought on it, though thinking further, I wonder if there is value to it to show 'signs of life' in the release notes?

@tbaeder -- do you have plans to continue to add support to the experimental constant expression evaluator?

If this is code that we have people actively working on with plans to bring it to completion, then I think showing signs of life in the release notes is a good idea. If we don't have anyone who is planning to bring this through to completion, I think we should seriously considering pulling it out of the tree rather than trying to maintain parallel constant expression evaluators. (We wouldn't be pulling it out of the tree because we don't like the design, so if someone wanted to resurrect it in the future because they planned to complete it, we'd gladly welcome it.)

I certainly plan to keep working on it. I have a few more such patches locally that you'll have pleasure reviewing I'm sure :). It think adding a small changelog note is fine of course.

Fantastic! As long as it's heading in the right direction rather than getting more and more stale, I'm happy to keep it in-tree. I'm fine either way on the release note.

This revision was automatically updated to reflect the committed changes.