LLVM 10.0.1 Bindings #679
LLVM 10.0.1 Bindings #679
Conversation
Initial steps of llvmv10 and llvmv10bindings
|
In additional, I prepared some diff-s in: For view code changes, etc. |
|
per-LLVM version fork is very bad Can we leverage C preprocessor or split out common parts? |
|
per-LLVM version fork is very bad It's successfully compiled and can be used "as basis".> Can we leverage C preprocessor or split out common parts? I do not shue: I send only changed files.99% of they is SWIG utility output.19.06.2021, 05:11, "Jay Krell" ***@***.***>:
per-LLVM version fork is very bad
Can we leverage C preprocessor or split out common parts?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
m3-sys/llvm/llvmv10/src/M3CG_LLVM.m3 looks like 7,000 copy/pasted lines. For example, what you can maybe do, is split it up into multiple files. Or delegate varying functions to ifdefed C. Seriously. It is a huge mess otherwise. And ideally generated files would not even be checked in. But that is a different problem. I wonder how bad/slow it'd be to write out the LLVM "bitcode" instead of linking to LLVM. |
|
==
"19.06.2021, 10:31, "Jay Krell" ***@***.***>:
m3-sys/llvm/llvmv10/src/M3CG_LLVM.m3 looks like 7,000 copy/pasted lines.
Please don't do that.
For example, what you can maybe do, is split it up into multiple files.
Functions that are identical across multiple versions, need not be duplicated.
Or delegate varying functions to ifdefed C. Seriously.
It is a huge mess otherwise.
And ideally generated files would not even be checked in. But that is a different problem.
I wonder how bad/slow it'd be to write out the LLVM "bitcode" instead of linking to LLVM.
That would also help, at quite some cost.
==
(
ifdefed C language
I think that better way is adding "ifdef functional" in style Apple Modula-2 to our modern Modula-3.
)
m3-sys/llvm/llvmv10/src/M3CG_LLVM.m3 looks like 7,000 copy/pasted lines.
It doesn't only "looks". It is relly copied file with 3 .. 4 changed lines of code.
I pubic on Github this "LLVM 10.0.1 binding" in two variants:
-- N1 is resent in this pull request;
-- N2 placed indide URL from my first comment.
Please don't do that.
I _specialy_ don't copy whole catalog llvm9binding ( and catalog llvm9) because this will be broken history and "authors right / owning info", etc.
We need solve how present this "LLVM 10.X binding" and future bindings for LLVM 11.X , 12X and 13.X ( currently in developing stage).
For example, I can send "patch in one file" for patch[.exe] utility.
I wonder how bad/slow it'd be to write out the LLVM "bitcode" instead of linking to LLVM.
That would also help, at quite some cost.
Please, read Readme file:
LLVM ( whole "big LLVM" , not our relative small "binding") has very bugged code inside -(
I think any big project can not be based on "C language".
P.S.
ideally generated files would not even be checked in
Today I run m3swig.exe in VM with OS Windows.
And after this run m3pp in VM with Debian 10.X
( and compile m3gdb debugger in Debian 8.11.1)
Of course, this is "temporary solution" in style "RAD developing", but "all temporary is most persistent"
|
|
See LLVM 11.0.1 Bindings inside VictorMiasnikov@e908738 |
|
I really don't love this stuff but we have no official policies or authority so I guess squash&merge if you feel confident. |
|
LLVM 11.0.1 Bindings } essentially an unreproducible binary dump. Horrible. Today it is true, because "special version of SWIG" work very well. } guess squash&merge at fist we need solve the way: |
|
Possibly no longer relevant now that LLVM 13 has been added to the tree? |
|
} 06.12.2021, 13:09, "Eric Sessoms" ***@***.***>:
} Possibly no longer relevant now that LLVM 13 has been added to the tree?
Yes, I start testing LLVM 13. May be best way is doing this:
I think we can at first rename folder "LLVM9" and Co to "LLVM10", after this I prepare new variant of pool r-st.
( and small patch to revert to LLVM v9 state)
As results we will be have both LLVM13 and LLVM10 ( with possibility to revert by manual to LLVM9)
… 06.12.2021, 13:09, "Eric Sessoms" ***@***.***>:
Possibly no longer relevant now that LLVM 13 has been added to the tree?
|
|
This: and ( as variant): steal actual |
|
About "testing LLVM 13": I create release named "d5.11.9-ZZYYXX-20220208_13-48". See a) cm3-all_with_m3llvm-AMD64_LINUX-d5.11.9-AMD64_LINUX(Debian_11.3.0-1_and_{{GCC_11.3.0}})-2022-02-08_13-48__FIXed__by__VVM__2022-05-18_14-06__AMD64_LINUX__Target__cm3-3be819e.deb contain b) ...\ZZ v5.11.9-VC2019-20220208_13-48 16bit-Unicode ( 16-bit WIDECHAR ) AMD64_NT Target\ llvm13__and__llvm13bindings_cm3-all-AMD64_NT-d5.11.9-VC142(2019)-2022-02-08_13-48__FIXed__by__VVM__2022-04-26_17-22__16bit__Unicode__AMD64_NT__Target__cm3-69f22c9.7z |
Initial steps of
llvmv10
and
llvmv10bindings