Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EVM] [DO NOT MERGE] Add Ethereum stackification #714

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

PavelKopyl
Copy link
Contributor

@PavelKopyl PavelKopyl commented Oct 9, 2024

This includes:

  • splitting of critical edges
  • CFG implementation
  • stack shuffler with unittest
  • stack layout generator
  • optimized code transform
  • proper ordering of ARGUMENT instructions

Code Review Checklist

Purpose

Ticket Number

Requirements

  • Have the requirements been met?
  • Have stakeholder(s) approved the change?

Implementation

  • Does this code change accomplish what it is supposed to do?
  • Can this solution be simplified?
  • Does this change add unwanted compile-time or run-time dependencies?
  • Could an additional framework, API, library, or service improve the solution?
  • Could we reuse part of LLVM instead of implementing the patch or a part of it?
  • Is the code at the right abstraction level?
  • Is the code modular enough?
  • Can a better solution be found in terms of maintainability, readability, performance, or security?
  • Does similar functionality already exist in the codebase? If yes, why isn’t it reused?
  • Are there any best practices, design patterns or language-specific patterns that could substantially improve this code?

Logic Errors and Bugs

  • Can you think of any use case in which the
    code does not behave as intended?
  • Can you think of any inputs or external events
    that could break the code?

Error Handling and Logging

  • Is error handling done the correct way?
  • Should any logging or debugging information
    be added or removed?
  • Are error messages user-friendly?
  • Are there enough log events and are they
    written in a way that allows for easy
    debugging?

Maintainability

  • Is the code easy to read?
  • Is the code not repeated (DRY Principle)?
  • Is the code method/class not too long?

Dependencies

  • Were updates to documentation, configuration, or readme files made as required by this change?
  • Are there any potential impacts on other parts of the system or backward compatibility?

Security

  • Does the code introduce any security vulnerabilities?

Performance

  • Do you think this code change decreases
    system performance?
  • Do you see any potential to improve the
    performance of the code significantly?

Testing and Testability

  • Is the code testable?
  • Have automated tests been added, or have related ones been updated to cover the change?
    • For changes to mutable state
  • Do tests reasonably cover the code change (unit/integration/system tests)?
    • Line Coverage
    • Region Coverage
    • Branch Coverage
  • Are there some test cases, input or edge cases
    that should be tested in addition?

Readability

  • Is the code easy to understand?
  • Which parts were confusing to you and why?
  • Can the readability of the code be improved by
    smaller methods?
  • Can the readability of the code be improved by
    different function, method or variable names?
  • Is the code located in the right
    file/folder/package?
  • Do you think certain methods should be
    restructured to have a more intuitive control
    flow?
  • Is the data flow understandable?
  • Are there redundant or outdated comments?
  • Could some comments convey the message
    better?
  • Would more comments make the code more
    understandable?
  • Could some comments be removed by making the code itself more readable?
  • Is there any commented-out code?
  • Have you run a spelling and grammar checker?

Documentation

  • Is there sufficient documentation?
  • Is the ReadMe.md file up to date?

Best Practices

  • Follow Single Responsibility principle?
  • Are different errors handled correctly?
  • Are errors and warnings logged?
  • Magic values avoided?
  • No unnecessary comments?
  • Minimal nesting used?

Experts' Opinion

  • Do you think a specific expert, like a security
    expert or a usability expert, should look over
    the code before it can be accepted?
  • Will this code change impact different teams, and should they review the change as well?

@PavelKopyl PavelKopyl marked this pull request as draft October 9, 2024 18:31
@PavelKopyl PavelKopyl changed the title [EVM] Add Ethereum stackification [EVM] [DO NOT MERGE] Add Ethereum stackification Oct 9, 2024
Copy link

github-actions bot commented Oct 9, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Collaborator

@akiramenai akiramenai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please handle dead arguments properly.
Example:

; Function Attrs: nounwind
define i256 @foo(i256 %a1, i256 %a2, i256 %a3) #0 {
  %x1 = add i256 %a1, %a1
  ret i256 %x1
}

; Function Attrs: nounwind
define i256 @wat(i256 %a1, i256 %a2, i256 %a3) #0 {
  %x1 = add i256 %a2, %a2
  ret i256 %x1
}

; Function Attrs: nounwind
define i256 @wat2(i256 %a1, i256 %a2, i256 %a3) #0 {
  %x1 = add i256 %a2, %a3
  ret i256 %x1
}

; Function Attrs: nounwind
define i256 @bar() #0 {
  %res = call i256 @foo(i256 1, i256 2, i256 3)
  ret i256 %res
}

Codegen:

foo:                                    ; @foo
; %bb.0:
	JUMPDEST
	DUP1
	ADD
	SWAP1
	JUMP
                                        ; -- End function
	.globl	wat                             ; -- Begin function wat
wat:                                    ; @wat
; %bb.0:
	JUMPDEST
	DUP1
	ADD
	SWAP1
	JUMP
                                        ; -- End function
	.globl	wat2                            ; -- Begin function wat2
wat2:                                   ; @wat2
; %bb.0:
	JUMPDEST
	SWAP1
	ADD
	SWAP1
	JUMP
                                        ; -- End function
	.globl	bar                             ; -- Begin function bar
bar:                                    ; @bar
; %bb.0:
	JUMPDEST
	PUSH4 @.FUNC_RET0
	PUSH1 3
	PUSH1 2
	PUSH1 1
	PUSH4 @foo
	JUMP
.FUNC_RET0:
	JUMPDEST
	SWAP1
	JUMP

@PavelKopyl PavelKopyl force-pushed the ef-stackification branch 2 times, most recently from ff232c6 to 5771d35 Compare November 16, 2024 09:07
ARGUMENT instructions should always be located at the beginning
of a MF`s entry basic block and be ordered in ascending order
of their operand values.
@PavelKopyl PavelKopyl force-pushed the ef-stackification branch 2 times, most recently from 6cc4506 to fe7ccda Compare November 25, 2024 17:30
Original idea and some code parts were taken from
the Ethereum`s compiler (solc) stackification algorithm.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants