anza-xyz / move

Move compiler targeting llvm supported backends
https://discord.gg/wFgfjG9J
Apache License 2.0
108 stars 33 forks source link

Add mv2llvm.sh #300

Closed jcivlin closed 6 months ago

jcivlin commented 1 year ago

From script description:

### Use this script to run all .mv files in a given directory thru `move-mv-llvm-compiler``.
###
### It is particularly convenient in combination with aptos compiler, for example the following line will
### call aptos move compiler (which supports move iterator, lambda and inline) and compile all files in the directory
### provided in `--package-dir` and will produce the bytecode (.mv files) in the directory provided in --output-dir:
### ./aptos move compile --package-dir  /home/sol/work/git/aptos/aptos-core/aptos-move/framework/move-stdlib --output-dir /tmp/aptos-stdlib
###
### Then run this script as
### mv2llvm.sh --dir /tmp/aptos-stdlib/build/MoveStdlib/bytecode_modules --mv2llvm [path to move-mv-llvm-compiler]
### Look for produced .ll files in the directory `/tmp/aptos-stdlib/build`.

In particular I got some results on Aptos stdlib:

sol@dev-equinix-new-york-2:~/work/git/aptos/aptos-core/target/debug:main u=$ ll ~/tmp/aptos-stdlib/build/MoveStdlib/bytecode_modules/
total 56
drwxr-xr-x 3 sol users 4096 Aug 22 22:20 ./
drwxr-xr-x 5 sol users 4096 Aug 22 22:09 ../
-rw-r--r-- 1 sol users  454 Aug 22 22:09 acl.mv
-rw-r--r-- 1 sol users   92 Aug 22 22:09 bcs.mv
-rw-r--r-- 1 sol users  817 Aug 22 22:09 bit_vector.mv
drwxr-xr-x 2 sol users 4096 Aug 22 22:20 build/
-rw-r--r-- 1 sol users  626 Aug 22 22:09 error.mv
-rw-r--r-- 1 sol users 2205 Aug 22 22:09 features.mv
-rw-r--r-- 1 sol users  904 Aug 22 22:09 fixed_point32.mv
-rw-r--r-- 1 sol users  106 Aug 22 22:09 hash.mv
-rw-r--r-- 1 sol users 1194 Aug 22 22:09 option.mv
-rw-r--r-- 1 sol users  130 Aug 22 22:09 signer.mv
-rw-r--r-- 1 sol users  923 Aug 22 22:09 string.mv
-rw-r--r-- 1 sol users 1513 Aug 22 22:09 vector.mv
sol@dev-equinix-new-york-2:~/work/git/aptos/aptos-core/target/debug:main u=$ ll ~/tmp/aptos-stdlib/build/MoveStdlib/bytecode_modules/build/
total 80
drwxr-xr-x 2 sol users  4096 Aug 22 22:20 ./
drwxr-xr-x 3 sol users  4096 Aug 22 22:20 ../
-rw-r--r-- 1 sol users   244 Aug 22 22:24 bcs.ll
-rw-r--r-- 1 sol users  9598 Aug 22 22:24 error.ll
-rw-r--r-- 1 sol users 42174 Aug 22 22:24 fixed_point32.ll
-rw-r--r-- 1 sol users   300 Aug 22 22:24 hash.ll
-rw-r--r-- 1 sol users  1038 Aug 22 22:24 signer.ll
-rw-r--r-- 1 sol users   640 Aug 22 22:24 vector.ll

Out of 11 .mv inputs move-mv-llvm-compiler successfully processed 6. 5 inputs failed, future analysis is required.

jcivlin commented 1 year ago

We already have a directory for non-compiler scripts and programs language/tools/move-mv-llvm-compiler/utils. How about moving this script there to avoid proliferating subdirs for related purposes?

This was my original intent too, but when I looked inside, I found files seemed related to testing, so I created a new directory tools.

dmakarov commented 1 year ago

We already have a directory for non-compiler scripts and programs language/tools/move-mv-llvm-compiler/utils. How about moving this script there to avoid proliferating subdirs for related purposes?

This was my original intent too, but when I looked inside, I found files seemed related to testing, so I created a new directory tools.

No, the files there are not only for testing. It’s a collection of tools or utils that aid development, testing, continuous integration etc, not related to the main application move-mv-llvm-compiler source code.

jcivlin commented 1 year ago

We already have a directory for non-compiler scripts and programs language/tools/move-mv-llvm-compiler/utils. How about moving this script there to avoid proliferating subdirs for related purposes?

This was my original intent too, but when I looked inside, I found files seemed related to testing, so I created a new directory tools.

No, the files there are not only for testing. It’s a collection of tools or utils that aid development, testing, continuous integration etc, not related to the main application move-mv-llvm-compiler source code.

It does not look very organized and I hope one day it will be. Why should I add to this if the new script is definitely falls into the category of tools?

sol@dev-equinix-new-york-2:~/work/git/move/language/tools/move-mv-llvm-compiler:llvm-sys *$% u+56$ ll -R utils 
utils:
total 20
drwxr-xr-x  3 sol users 4096 Jul  9 04:28 ./
drwxr-xr-x 10 sol users 4096 Aug 23 22:45 ../
-rwxr-xr-x  1 sol users  225 Jul  9 04:28 pre-commit-cargo-fmt*
-rwxr-xr-x  1 sol users  480 Jul  9 04:28 setup.py*
drwxr-xr-x  3 sol users 4096 Aug  1 05:10 testgen/

utils/testgen:
total 124
drwxr-xr-x 3 sol users 4096 Aug  1 05:10 ./
drwxr-xr-x 3 sol users 4096 Jul  9 04:28 ../
-rw-r--r-- 1 sol users  305 Aug  1 05:10 Cargo.toml
-rw-r--r-- 1 sol users  313 May 10 19:05 cast-u128-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  328 May 10 19:05 cast-u128-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  358 May 10 19:05 cast-u128-to-u64-rangechk-abort.move
-rw-r--r-- 1 sol users  301 May 10 19:05 cast-u128-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u16-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  418 May 10 19:05 cast-u256-to-u128-rangechk-abort.move
-rw-r--r-- 1 sol users  313 May 10 19:05 cast-u256-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  328 May 10 19:05 cast-u256-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  358 May 10 19:05 cast-u256-to-u64-rangechk-abort.move
-rw-r--r-- 1 sol users  301 May 10 19:05 cast-u256-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  307 May 10 19:05 cast-u32-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u32-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  307 May 10 19:05 cast-u64-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  322 May 10 19:05 cast-u64-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u64-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  259 May 10 19:05 eq-u128.move
-rw-r--r-- 1 sol users  187 May 10 19:05 eq-u16.move
-rw-r--r-- 1 sol users  259 May 10 19:05 eq-u256.move
-rw-r--r-- 1 sol users  197 May 10 19:05 eq-u32.move
-rw-r--r-- 1 sol users  217 May 10 19:05 eq-u64.move
-rw-r--r-- 1 sol users  177 May 10 19:05 eq-u8.move
-rw-r--r-- 1 sol users  262 May 10 19:05 neq-u128.move
-rw-r--r-- 1 sol users  190 May 10 19:05 neq-u16.move
-rw-r--r-- 1 sol users  262 May 10 19:05 neq-u256.move
-rw-r--r-- 1 sol users  200 May 10 19:05 neq-u32.move
-rw-r--r-- 1 sol users  220 May 10 19:05 neq-u64.move
-rw-r--r-- 1 sol users  180 May 10 19:05 neq-u8.move
drwxr-xr-x 2 sol users 4096 Jul  9 04:28 src/

utils/testgen/src:
total 16
drwxr-xr-x 2 sol users 4096 Jul  9 04:28 ./
drwxr-xr-x 3 sol users 4096 Aug  1 05:10 ../
-rw-r--r-- 1 sol users 8000 Jul  9 04:28 main.rs
dmakarov commented 1 year ago

We already have a directory for non-compiler scripts and programs language/tools/move-mv-llvm-compiler/utils. How about moving this script there to avoid proliferating subdirs for related purposes?

This was my original intent too, but when I looked inside, I found files seemed related to testing, so I created a new directory tools.

No, the files there are not only for testing. It’s a collection of tools or utils that aid development, testing, continuous integration etc, not related to the main application move-mv-llvm-compiler source code.

It does not look very organized and I hope one day it will be. Why should I add to this if the new script is definitely falls into the category of tools?

sol@dev-equinix-new-york-2:~/work/git/move/language/tools/move-mv-llvm-compiler:llvm-sys *$% u+56$ ll -R utils 
utils:
total 20
drwxr-xr-x  3 sol users 4096 Jul  9 04:28 ./
drwxr-xr-x 10 sol users 4096 Aug 23 22:45 ../
-rwxr-xr-x  1 sol users  225 Jul  9 04:28 pre-commit-cargo-fmt*
-rwxr-xr-x  1 sol users  480 Jul  9 04:28 setup.py*
drwxr-xr-x  3 sol users 4096 Aug  1 05:10 testgen/

utils/testgen:
total 124
drwxr-xr-x 3 sol users 4096 Aug  1 05:10 ./
drwxr-xr-x 3 sol users 4096 Jul  9 04:28 ../
-rw-r--r-- 1 sol users  305 Aug  1 05:10 Cargo.toml
-rw-r--r-- 1 sol users  313 May 10 19:05 cast-u128-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  328 May 10 19:05 cast-u128-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  358 May 10 19:05 cast-u128-to-u64-rangechk-abort.move
-rw-r--r-- 1 sol users  301 May 10 19:05 cast-u128-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u16-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  418 May 10 19:05 cast-u256-to-u128-rangechk-abort.move
-rw-r--r-- 1 sol users  313 May 10 19:05 cast-u256-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  328 May 10 19:05 cast-u256-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  358 May 10 19:05 cast-u256-to-u64-rangechk-abort.move
-rw-r--r-- 1 sol users  301 May 10 19:05 cast-u256-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  307 May 10 19:05 cast-u32-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u32-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  307 May 10 19:05 cast-u64-to-u16-rangechk-abort.move
-rw-r--r-- 1 sol users  322 May 10 19:05 cast-u64-to-u32-rangechk-abort.move
-rw-r--r-- 1 sol users  295 May 10 19:05 cast-u64-to-u8-rangechk-abort.move
-rw-r--r-- 1 sol users  259 May 10 19:05 eq-u128.move
-rw-r--r-- 1 sol users  187 May 10 19:05 eq-u16.move
-rw-r--r-- 1 sol users  259 May 10 19:05 eq-u256.move
-rw-r--r-- 1 sol users  197 May 10 19:05 eq-u32.move
-rw-r--r-- 1 sol users  217 May 10 19:05 eq-u64.move
-rw-r--r-- 1 sol users  177 May 10 19:05 eq-u8.move
-rw-r--r-- 1 sol users  262 May 10 19:05 neq-u128.move
-rw-r--r-- 1 sol users  190 May 10 19:05 neq-u16.move
-rw-r--r-- 1 sol users  262 May 10 19:05 neq-u256.move
-rw-r--r-- 1 sol users  200 May 10 19:05 neq-u32.move
-rw-r--r-- 1 sol users  220 May 10 19:05 neq-u64.move
-rw-r--r-- 1 sol users  180 May 10 19:05 neq-u8.move
drwxr-xr-x 2 sol users 4096 Jul  9 04:28 src/

utils/testgen/src:
total 16
drwxr-xr-x 2 sol users 4096 Jul  9 04:28 ./
drwxr-xr-x 3 sol users 4096 Aug  1 05:10 ../
-rw-r--r-- 1 sol users 8000 Jul  9 04:28 main.rs

In my opinion, it's cleaner to keep all such scripts in one place than clutter the space with a new directory for every new loosely defined category of scripts.

ksolana commented 1 year ago

yeah let's keep it in the utils as Dmitri mentioned. we can always reorganize into a new directory once we have more scripts.

ksolana commented 1 year ago

the script itself LGTM.

dmakarov commented 6 months ago

Is this going to be hanging forever?

dmakarov commented 6 months ago

Closing due to over 6 months of being inactive. Please, reopen for new development.