compiler icon indicating copy to clipboard operation
compiler copied to clipboard

Generated llvm code is not forward compatible

Open ghost opened this issue 7 years ago • 9 comments

System: Arch Linux Clang version: 5.0.1

I tested building test_hack test project and it fails with:

prog.ll:42:25: error: expected comma after load's type
        %r11 = load void(i32)**@_Z10anon_fn_40i.ptr

After searching for the error online, I see that it works with previous versions of LLVM (https://github.com/MLton/mlton/issues/138). Shouldn't LLVM api be used instead to ensure compatibility?

ghost avatar Feb 10 '18 16:02 ghost

hi, thanks for the feedback, and pointer on how to fix it..

ok I hadn't used this in ages. I just emitted LLVM source as a quick way of getting this project going - e.g. without having to bother linking with the LLVM library.

You're right that the LLVM API would be a much more stable path.

This is at least structured to allow different code-gen layers to be slotted in, pretty much. I can take a look at how much effort would be involved in making a propper API based backend, or perhaps at least see how much would need to change to use the latest version of LLVM

Another option might be to add something transpiling to C (or c++) . That might sound lame, but it's very portable, and there is still #line for some error reporting (I actually wish I'd started out that way). indeed the long term plan was 2-way transpiling of as much as possible

dobkeratops avatar Feb 10 '18 20:02 dobkeratops

(incase you are curious: r.e. "different back ends" - the intention was to implement different versions of the interface defined in codegen.h (class CodeGen, CodeGen::emit_*** ) .. the compiler passes an object through the tree calling various methods for primitives like load/store,evaluating primitives etc. Those evaluate/return 'class CgValue' intermediates which I think carried information to build the expressions written out. However I never implemented anything other than the human-readable LLVM IR back end)

dobkeratops avatar Feb 10 '18 22:02 dobkeratops

FYI, i've taken a look at fixing the output.. haven't managed to do it yet, it's quite fiddly. I fixed a few cases (it seems getelementptr, load, etc require ... ty, ty ptr ,.. (added something for emitting the 'pointee type') but run into more confusion. (I can push what I've fixed so far onto GitHub if you like)

Not sure what I'll do.. I'm tempted to throw in the towel and accept this as having died of bit-rot, it depends how interested you or anyone else is in this.

it may be better to pursue the similar active projects (zig, c2) and contribute to those. Writing a C backend (maybe my preferred option) or LLVM API would be quite a lot of effort IMO.

i'll take a break and think about it some more

dobkeratops avatar Feb 11 '18 10:02 dobkeratops

What version of llvm will it be compatible with ?

AyoubCoding21 avatar Mar 02 '24 11:03 AyoubCoding21

@dobkeratops what version of llvm is it compatible is it clang-11 or sth like that i wanna maintain the project

AyoubCoding21 avatar Mar 02 '24 11:03 AyoubCoding21

also push the fixed changes to github

AyoubCoding21 avatar Mar 02 '24 11:03 AyoubCoding21

hat version of llvm is it compatible is it clang-11 or sth like that i wanna maintain the project

Hi, thanks for your interest ! I can't remember off hand but i can try and check. What I can tell you for sure is I was compiling this about 9(!!!) years ago , in the few months after the very first JAI videos

if you want to tinker with it and push changes i'll certainly take PR's. I'm unlikely to change this myself anytime soon.. so it's unlkely you'll get conflicts. you might find if you poke around in 'codegen.cpp' you can fix it.

I regret that I didn't just make it spit out C source - you might be able to figure out how to do that aswell.

I did figure it would be good to get this working again because even all abandoned code out there contributes to AI training data in the end.

dobkeratops avatar Mar 02 '24 15:03 dobkeratops