- User Since
- Jul 3 2019, 10:12 AM (15 w, 5 h)
Tue, Oct 1
Fri, Sep 20
Sep 13 2019
Sep 12 2019
Added a FIXME to reflect the intention to move the interpreter to its own library
Thanks for looking into the problem - sorry for the delay!
Sep 11 2019
reset accidentally changed tests
Sep 10 2019
removed declarations with no definitions
Totally missed that - thanks for noticing. I must have forgotten to remove stuff from the header since clang/gcc don't warn about it.
I'll get hold of a Windows machine soon-ish and I'll make sure to fix this problem.
Sep 9 2019
I am providing definitions in the C++ file - the problem is that they are not available in the header before the extern declaration. The methods are available at the site of the extern definition.
gcc and clang accept this, so does Visual Studio 2019. This feels like an incorrect implementation of extern templates in Visual Studio?
Sep 4 2019
@jfb suggested I add @rnk: I was wondering if you have any suggestions on how to fix the msvc warnings/errors? I'd be grateful if I had some feedback on what features of C++ I should avoid using and what I should replace them with.
The existing evaluator is not a separate library to start with. Given the tangling between ExprConstants.cpp and the AST nodes, I don't really see any elegant way of dealing with this problem.
Does anyone have any suggestions on how to fix the MSVC problems? I am trying to get access to a Windows machine, but it's not guaranteed.
Merged clangInterp and clangAST into a single library while keeping Interp in a separate folder.
This is required since clangInterp needs access to the AST, but the intry points to the interpreter
are also in AST.
Thanks for identifying these issues - I fixed the cycle detected by modules since then, however I wasn't aware of the issue with shared libs until now.
Sep 3 2019
Sep 2 2019
Aug 31 2019
Aug 30 2019
Added more features
Aug 29 2019
Aug 27 2019
replaced llvm::make_unique with std::make_unique
refactoring + implemented changes
Aug 13 2019
The old path-based approach is slow for most operations, while the new pointer-based approach is fast for the most common ones.
For read/write/update operations, it is enough to check the pointer and at most a single descriptor to ensure whether the operation
can be performed. For some operations, such as some pointer comparisons, in the worst case the old-style path can be reproduced by
following the pointers produced through the getBase method, allowing us to implement everything.
updated diff, implemented requested changes
Implemented @zygoloid's suggestions
Aug 4 2019
Implemented suggestions from @rsmith.
Jul 31 2019
I have applied most of the changes you suggested to my HEAD which had significantly more functionality, including a replacement of Opcodes.in with TableGen.
Quite a few of your concerns are answered by the features I have added between submitting the patch and now. The interpreter now stands at ~6k LOC.
removed redundant check
replaced char with signed char
Just checked: tests pass with UBSan.
Updated comments about bitcast
Jul 30 2019
Jul 29 2019
We can add a separate integer type which tracks all the additional information required by __builtin_constant_p and compile all integers to it in this context. A later patch added an APInt fallback to the interpreter if an integral cannot be mapped to a type supported by the VM - this mechanism could be used to implement the fallback for contexts which cast pointers to integers.
How do you intend to represent pointers cast to integer types? Allocating 64 bits of state for a 64-bit integer is insufficient to model that case.
Jul 8 2019
Fixed read of call stack depth
Jul 3 2019
Fixed typo in command line flags