Treat builtins separately in Yul AST #15347

clonker · 2024-08-20T07:24:24Z

Depends on

Yul: Remove boolType and defaultType from dialect #15332

libyul/ASTForward.h

cameel

Here's some initial feedback. Not a full review yet.

libyul/Builtins.h

libyul/AsmJsonConverter.cpp

libyul/Dialect.cpp

libyul/ObjectOptimizer.cpp

libyul/AST.h

cameel

I haven't managed go get through it all yet, but here's some feedback so far.

I think we may still need some adjustments in EVMDialect implementation. Also, I think that Dialect should be stored in Object, though that could be done in a separate PR to avoid making this one even larger.

cameel · 2024-10-15T20:38:57Z

libyul/AST.h

+/// Builtin function
+struct BuiltinName { langutil::DebugData::ConstPtr debugData; BuiltinHandle handle; };
+/// Identifier for function names
+using FunctionHandle = std::variant<YulName, BuiltinHandle>;


We could add a bit more detail here:

Suggested change

/// Builtin function

struct BuiltinName { langutil::DebugData::ConstPtr debugData; BuiltinHandle handle; };

/// Identifier for function names

using FunctionHandle = std::variant<YulName, BuiltinHandle>;

/// AST Node representing a reference to one of the built-in functions (as defined by the dialect).

/// In the source it's an actual name, while in the AST we only store a handle that can be used to find the the function in the Dialect.

struct BuiltinName { langutil::DebugData::ConstPtr debugData; BuiltinHandle handle; };

/// Type that can refer to both user-defined functions and built-ins.

/// Technically the AST allows these names to overlap, but this is not possible to represent in the source.

using FunctionHandle = std::variant<YulName, BuiltinHandle>;

cameel · 2024-10-15T20:42:18Z

libyul/YulName.h

-#include <libyul/YulString.h>
-
 namespace solidity::yul
 {
+class YulString;


Any advantage to doing this? It seems that you'd want to include YulString.h whenever you use YulName anyway. And we'll unify them eventually.

The advantage is that I am now including YulName.h in ASTForward.h. This is required if I want to define FunctionName in there, as the identifier for a user defined function is a YulName (or currently: YulString). So by making YulName.h forwarding, I don't implicitly include YulString.h in ASTForward.h.

Wouldn't it be more typical for just forward-declare YulName there? Or, I guess, redefine since it's just an alias.

In any case, it's fine, I was just curious why it was done this way.

Right, redefining is an option :)

cameel · 2024-10-15T21:17:51Z

libyul/Dialect.h

 	/// @returns the builtin function of the given name or a nullptr if it is not a builtin function.
-	virtual BuiltinFunction const* builtin(YulName /*_name*/) const { return nullptr; }
+	virtual std::optional<BuiltinHandle> builtin(std::string_view /*_name*/) const { return std::nullopt; }
+
+	virtual BuiltinFunction const& builtinFunction(BuiltinHandle const&) const;


These names are a bit inconsistent given that, below, the ones ending in Function return a handle, while here it's the opposite. And builtin() and builtinFunction() sound too much like the same thing.

A better convention might be to keep builtin() as the one returning BuiltinFunction, and rename the other one to findBuiltin(). This better reflects which one is doing more work.

Then the ones ending with Function could be renamed to end with Handle or FunctionHandle. Or maybe left as is - no longer having builtinFunction() that resembles them already makes it less confusing.

Also, docstring needs updating. Now it's nullopt, not nullptr. You could informally say just "null".

cameel · 2024-10-15T21:23:44Z

libyul/Dialect.h

Looks like Dialect::fixedFunctionNames() isn't implemented by any dialect. Back when we had the Ewasm dialect, it contained one name there: "main". I think we can remove it as an Ewasm left-over.

If you do want to keep it, then I guess it should be using returning either BuiltinHandles or strings.

cameel · 2024-10-15T21:53:58Z

libyul/Object.h

@@ -93,11 +95,12 @@ struct Object: public ObjectNode
 public:
 	/// @returns a (parseable) string representation.
 	std::string toString(
+		Dialect const& _dialect,


I think we should store the Dialect in the Object (or AST). After this PR the Object on its own is no longer enough to interpret the AST, even in non-source form. And also it's not like we can print it in arbitrary dialect and still get something that makes sense.

But that's probably better done as a separate refactor on top of it. The PR is already quite large and it would be harder to review these things together.

cameel · 2024-10-15T22:07:14Z

libyul/AsmParser.cpp

+		auto const raiseAssignToBuiltinError = [this](std::string const& _name) {
+			fatalParserError(6272_error, "Cannot assign to builtin function \"" + _name + "\".");
+		};


If this was pulled out because of verbatim, now you can put it back. Having it singled out like this is a bit distracting :)

Same with uninvokedBuiltinError() below. You can also use util::unreachable() to avoid having to return a dummy value there.

Also, shouldBreak would be better off called something like foundLastVariable or foundListEnd and be the loop condition (it could also be a do..while loop).

test/libyul/yulSyntaxTests/assignment_to_builtin.yul

libyul/backends/evm/EVMDialect.cpp

cameel · 2024-10-16T01:00:47Z

One more thing. Not sure if it's worth it at this point, since it's extra effort for you, but after going through most of the PR it seems to me that there is a way to split it into two smaller parts quite cleanly, and smaller PRs would get through review faster. I think that the introduction of BuiltinHandle and all the changes in the Dialect would make sense on their own. Then introducing FunctionName it into the AST could be a second step on top of that.

clonker · 2024-10-16T14:14:39Z

I'll do as you suggested and split the PR into two. It is more work for me but probably downstream more efficient, all things considered.

clonker · 2024-10-22T13:19:45Z

Comparing against current develop (including BuiltinHandles):

File (IR)	Time develop	Time PR	Change
openzeppelin	15.43 +- 0.06 s	14.86 +- 0.05 s	4.8%
uniswap-v4	60.75 +- 0.09 s	59.69 +- 0.08 s	1.7%
eigenlayer	278.43 +- 0.59 s	273.15 +- 1.18 s	1.9%

…ions from an AST FunctionName

github-actions · 2024-11-15T12:05:55Z

This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale label is removed.

clonker force-pushed the builtin_ast_element branch from d93fc88 to 5f7b564 Compare August 20, 2024 07:25

ethereum deleted a comment from stackenbotten Aug 20, 2024

clonker changed the base branch from develop to remove_yul_dialect_types August 20, 2024 11:04

clonker force-pushed the builtin_ast_element branch from 340ffbc to b69030d Compare August 20, 2024 11:05

ethereum deleted a comment from stackenbotten Aug 20, 2024

clonker added the has dependencies The PR depends on other PRs that must be merged first label Aug 20, 2024

ethereum deleted a comment from stackenbotten Aug 22, 2024

clonker force-pushed the builtin_ast_element branch from a5e3f71 to 52e9e4b Compare August 22, 2024 09:01

ekpyron reviewed Aug 22, 2024

View reviewed changes

libyul/ASTForward.h Outdated Show resolved Hide resolved

clonker force-pushed the builtin_ast_element branch 2 times, most recently from 39fdd32 to dec3a9d Compare August 26, 2024 08:17

ethereum deleted a comment from stackenbotten Aug 26, 2024

clonker force-pushed the builtin_ast_element branch from dec3a9d to 7370d5a Compare August 26, 2024 08:21

ethereum deleted a comment from stackenbotten Aug 26, 2024

clonker force-pushed the remove_yul_dialect_types branch 2 times, most recently from d73a5bf to ec2536e Compare August 27, 2024 08:43

clonker force-pushed the builtin_ast_element branch from 01fe1a4 to 108cf86 Compare August 27, 2024 09:14

clonker force-pushed the remove_yul_dialect_types branch 2 times, most recently from 03b01c1 to 4938075 Compare August 28, 2024 10:07

Base automatically changed from remove_yul_dialect_types to develop August 28, 2024 11:25

clonker force-pushed the builtin_ast_element branch 2 times, most recently from a78635f to 48de861 Compare September 19, 2024 07:18

clonker force-pushed the builtin_ast_element branch from 75ef5e6 to 4db506f Compare September 25, 2024 10:29

clonker force-pushed the builtin_ast_element branch 2 times, most recently from 3b9c384 to c05a6b2 Compare October 10, 2024 15:20

cameel reviewed Oct 10, 2024

View reviewed changes

clonker force-pushed the builtin_ast_element branch 5 times, most recently from 599255e to f0e9f4d Compare October 15, 2024 12:23

cameel reviewed Oct 16, 2024

View reviewed changes

clonker force-pushed the builtin_ast_element branch from f0e9f4d to ea36743 Compare October 22, 2024 12:37

clonker mentioned this pull request Oct 22, 2024

Yul: Object contains dialect #15534

Merged

cameel changed the base branch from develop to yul_object_contains_dialect October 30, 2024 20:27

cameel added the has dependencies The PR depends on other PRs that must be merged first label Oct 30, 2024

clonker force-pushed the yul_object_contains_dialect branch from a59ec52 to 371647c Compare October 31, 2024 09:23

Base automatically changed from yul_object_contains_dialect to develop October 31, 2024 16:46

clonker added 4 commits November 1, 2024 09:47

Yul: Add utilities to resolve function name strings and builtin funct…

10ce6f3

…ions from an AST FunctionName

Yul EVM dialect: Add auxiliary builtin handles

c7c91c8

Yul: Add builtin AST element

4cc88f7

Add Yul tests to test erroneous assignment to builtins and numbers

a3ef44a

clonker force-pushed the builtin_ast_element branch from ea36743 to a3ef44a Compare November 1, 2024 09:11

github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Nov 15, 2024

cameel removed the stale The issue/PR was marked as stale because it has been open for too long. label Nov 16, 2024

ekpyron added the 🟡 PR review label label Nov 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Treat builtins separately in Yul AST #15347

Treat builtins separately in Yul AST #15347

clonker commented Aug 20, 2024 •

edited

Loading

cameel left a comment

cameel left a comment •

edited

Loading

cameel Oct 15, 2024

cameel Oct 15, 2024

clonker Oct 16, 2024

cameel Oct 16, 2024

clonker Oct 16, 2024

cameel Oct 15, 2024 •

edited

Loading

cameel Oct 15, 2024

cameel Oct 15, 2024

cameel Oct 15, 2024 •

edited

Loading

cameel Oct 15, 2024

cameel Oct 15, 2024

cameel commented Oct 16, 2024 •

edited

Loading

clonker commented Oct 16, 2024

clonker commented Oct 22, 2024

github-actions bot commented Nov 15, 2024

Treat builtins separately in Yul AST #15347

Are you sure you want to change the base?

Treat builtins separately in Yul AST #15347

Conversation

clonker commented Aug 20, 2024 • edited Loading

cameel left a comment

Choose a reason for hiding this comment

cameel left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cameel Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cameel Oct 15, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cameel commented Oct 16, 2024 • edited Loading

clonker commented Oct 16, 2024

clonker commented Oct 22, 2024

github-actions bot commented Nov 15, 2024

clonker commented Aug 20, 2024 •

edited

Loading

cameel left a comment •

edited

Loading

cameel Oct 15, 2024 •

edited

Loading

cameel Oct 15, 2024 •

edited

Loading

cameel commented Oct 16, 2024 •

edited

Loading