Medium Risk
https://github.com/vyperlang/vyper/blob/b01cd686aa567b32498fefd76bd96b0597c6f099/vyper/cli/vyper_ir.py#L47-L51
https://github.com/vyperlang/vyper/blob/b01cd686aa567b32498fefd76bd96b0597c6f099/vyper/cli/vyper_ir.py#L35-L38
Fang allows users to specify whether they would like their program outputted as ir
, opt_ir
, asm
, or bytecode
. However, the actual behavior is that ir
will return optimized IR, and opt_ir
will not return anything.
When users call fang ...
, the call is handled by cli/vyper_ir.py
. One of the passed arguments is a list of formats to output. From the help doc:
"Format to print csv list of ir,opt_ir,asm,bytecode"
However, if we look at the compile_to_ir()
function, we can see that, in the event that ir
is passed, it automatically optimizes the IR and saves it as compiler_data["ir"]
, rather than compiler_data["opt_ir"]
.
compiler_data = {}
ir = IRnode.from_list(s_expressions[0])
ir = optimizer.optimize(ir)
if "ir" in output_formats:
compiler_data["ir"] = ir
Further, we can see that if opt_ir
is included in the list of formats, it is not processed and nothing happens. There is no way to save any value in compiler_data["opt_ir"]
.
Later, when we process outputs, we iterate over the possible output types:
for key in ("ir", "opt_ir", "asm", "bytecode"):
if key in compiler_data:
print(compiler_data[key])
Since there will never be any key called opt_ir
in compiler_data
, this option will be skipped.
Fang will generate optimized IR when we request unoptimized IR. This can lead to problems for low level developers who are using Fang specifically so they can specify that their IR should remain exactly as they wrote it. This can lead to unexpected behavior, such as gas prices and codesize not being exactly as predicted.
It will skip generating the optimized IR when asked, which is less of an issue.
Manual Review
Split the generation of IR via Fang into two options: one for ir
that skips the optimization step, and another for opt_ir
that uses the current implementation.