[M3devel] LLVM builder modes Int/Ext/StAlone
Jay K
jay.krell at cornell.edu
Mon Sep 14 09:05:21 CEST 2015
I agree development never ends.One should always keep in mind active development and not treat it as rare/unusual.
The way to get assembly output, I claim, is to fiddle with the config file.
For example, add -S or -s on the C compiler command line.
I don't believe it is ever useful/required to output assembly for the entire treeusing a C compiler or LLVM.
It is only needed very temporarily/modally for focused debugging.Even if development never ends.
Unless maybe you are analysing picking up a new LLVM or such?
You usually trust the C compiler and LLVM to translate correctlyfrom your output. Usually you only care to look at your output.Therefore -keep.
I can be flexible on this.Still, it doesn't require a mode I Think.
Yes I have about same meaning of "internal" as you.I guess there are multiple variables: separate process? separate .so/dll? output the cm3cg files? Up until now, they have always coincided. In terms of the builder though, it would not likely do anything different for static linking vs. dynamic linking of LLVM. It should still just make the same function calls. Unless maybe you want to use dlopen/dlsym? Which is really yet another mode "dynamic dynamic". I think it is really just if the cm3cg files are output.
I should see if I can eliminate the C mode, in order to "prove"I'm not being hypocritical here. I think it was just for easieraccess to the RunCC or such. I'll try to pass that address tothe C backend and then go back to InternalObject mode..
If C mode is just InternalObject, then probably LLVM should be too.Again, builder should just decide to produce the IR files or not.The other decisions are other variables that Builder doesn't care about.One does have to instantiate the right backend somewhere. It isn't a huge deal though. Builder can temporarily be a mess and we canclean it up later.
> Actually, I'd also like to be able to set it up so m3cgcat gets > run on .mc/.mc files and llvm-dis on .mb/.ib files, by cm3. It > would just save a couple of manual steps that I am typing over > and over, slowing down the debug process.
I think this is just a matter of a few lines of quake. Can you look at what I did for m3cgcat and the C mode? Here:
cm3cg.common:
if not defined("USE_C_BACKEND_VIA_M3CGCAT") USE_C_BACKEND_VIA_M3CGCAT = FALSEend
and then:
if USE_C_BACKEND_VIA_M3CGCATM3_BACKEND_MODE = "ExternalObject"
proc m3_backend(source, object, optimize, debug) is ret_code = try_exec("m3cgcat", "-in-binary:" & source, "-out-c:" & source & ".c") if not equal(ret_code, 0) return ret_code end return compile_c(source & ".c", object, [ ], FALSE, TRUE)endend
I don't remember any problems with this, just that it is slower to output the files.
If you wanted to see the C compiler output, here you'd add -S or -s or -FA or such.No need to change the mode.There is something subtle here I'm not explaining well, how this is usefulbut doesn't need to be automated, because it is used rarely and only at small scale.
Like, I had no need for a CToAssembly mode.
Ultimately "internal" modes are probably always faster, and the draw is strongfor that reason. The C backend is slow enough w/o "external" making it slower.
- Jay
> Date: Sat, 12 Sep 2015 19:13:27 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] LLVM builder modes Int/Ext/StAlone
>
> My inference has been that "internal" means the whole compilation job
> is done by code linked in (not necessarily statically) to cm3, e.g.,
> using the integrated x86 backend. "external" means there are one or
> more separate executables to run after the front end, e.g., m3cc
> and as, or m3llvm, llc, asm, etc.
>
> I definitely want the possibility of keeping assembly form for development work,
> even when 'as' is run. And we should assume that occasional development work
> will continue forever. Disassembling object code will lose sometimes very
> useful information, compared to keeping assembly as originally generated as
> a side output.
>
> Actually, I'd also like to be able to set it up so m3cgcat gets
> run on .mc/.mc files and llvm-dis on .mb/.ib files, by cm3. It
> would just save a couple of manual steps that I am typing over
> and over, slowing down the debug process.
>
> On 09/12/2015 06:50 PM, Jay K wrote:
> > Those comments were from me, since I went through
> > and 1) added the C mode 2) tried to clean up what
> > I percieve as rather messy, and still messy.
> >
> >
> > You helped my vocabulary here -- it should be "cartesian factored".
> > Rather than every "product" be its own case.
> >
> >
> > I moved it toward that, but it still confusing.
> >
> >
> > Basically you want a set of available steps, and
> > then just sequence them, possibly omitting some of them.
> >
> >
> > I can see how you might have roughly 10 choices,
> > depending on if you are outputing bitcode or LLVM assembly
> > or building LLVM data structures, and linking to LLVM or not,
> > and LLVM is producing assembly or object files.
> >
> >
> > I would suggest that LLVM produing assembly is not a useful choice.
> > Remove that from the matrix.
> > Have it produce object files if you can.
> > For debugging, you can fiddle with the switches or dump the files
> > afterward.
> >
> >
> > If you are producing cm3cg IR files like for m3cc, likely you don't need builder support.
> > You can use the "external object" mode plus config file stuff.
> > I started that way for C and didn't change the builder initially.
> > But it was slower. I don't remember why i needed builder support,
> > vs. the existing "internal object" mode,
> > maybe to more easily reuse the existing support for compiling C.
> > My mode is kind of "internal plus run some quake code".
> > I guess I could setup linkage so the C backend could call the quake
> > code w/o the builder knowing about it.
> > Maybe I should try that, so we can get back to the original set of modes.
> >
> >
> > Basically "external" means "produce cm3cg IR files".
> > "Internal" means don't produce them.
> > And then "assembly" means "run assembler after backend"
> > and "object" means don't run assembler because we already have objects.
> >
> >
> > Whether or not the m3cg IR files are being converted to C and then objects
> > or gcc internals and then objects, or LLVM internals and then objects,
> > the builder doesn't need to know or act differently.
> > It just runs the quake function m3_backend or such, and it decides,
> > via a separate factor from mode to run llvm or cm3cg on the IR file.
> >
> >
> > Basically, let's say we have n different external backends producing
> > object files. That doesn't imply any new modes. But some other variable
> > that affects the quake code that runs cm3cg.
> >
> >
> > Thank you for the confirmation as to which mode you are using.
> >
> >
> > - Jay
> >
> >
> >
> >
> > > Date: Fri, 11 Sep 2015 15:13:43 -0500
> > > From: rodney_bates at lcwb.coop
> > > To: m3devel at elegosoft.com
> > > Subject: Re: [M3devel] LLVM builder modes Int/Ext/StAlone
> > >
> > > Yes, I put in all the modes I thought of while working in there, as it's a lot easier
> > > to do it when you are familiar with the code than refamiliarize later. There were
> > > already some with comments like "No such back end". Only the StAloneLlvm ones
> > > have an actual back end. The others are intended for modes that link in at least
> > > some of llvm into cm3. As discussed, we may not want to do this.
> > >
> > > The only mode I have tried is StAloneLlvmAsm. This is running to compile completion
> > > on small examples and passing a good few of the compiler tests. Right now, I am working
> > > on the ones that pass using m3cc and fail using m3llvm, before trying to build the real code.
> > >
> > > On 09/10/2015 08:53 PM, Jay K wrote:
> > > > Here is what I get: some "crash", some "fail", some get the file format mixed up, some work!
> > > > 6 modes. 4 crash, 1 appears to work, 1 appears close
> > > >
> > > >
> > > > jair:m3core jay$ for a in \
> > > > IntLlvmObj \
> > > > IntLlvmAsm \
> > > > ExtLlvmObj \
> > > > ExtLlvmAsm \
> > > > StAloneLlvmObj \
> > > > StAloneLlvmAsm; \
> > > >
> > > > do rm AMD64_DARWIN/RT0.io ; echo $a;cm3 -DM3_BACKEND_MODE=$a -keep -commands; done
> > > >
> > > > IntLlvmObj
> > > > *** runtime error:
> > > > *** Segmentation violation - possible attempt to dereference NIL
> > > > *** pc = 0x1030edca3 = set_error_handler + 0x5b in ../src/M3CG.m3
> > > > ***
> > > >
> > > > IntLlvmAsm
> > > > *** runtime error:
> > > > *** Segmentation violation - possible attempt to dereference NIL
> > > > ***
> > > >
> > > > ExtLlvmObj
> > > > *** runtime error:
> > > > *** Segmentation violation - possible attempt to dereference NIL
> > > > *** pc = 0x10e8b0ca3 = set_error_handler + 0x5b in ../src/M3CG.m3
> > > >
> > > > ExtLlvmAsm
> > > > *** runtime error:
> > > > *** Segmentation violation - possible attempt to dereference NIL
> > > >
> > > > StAloneLlvmObj
> > > > m3llvm -b -d -o RT0.ib RT0.ic
> > > > llc -disable-fp-elim -filetype=obj -relocation-model=pic RT0.ib -o RT0.io
> > > >
> > > > => success?
> > > >
> > > > except for:
> > > > error: /Library/Developer/CommandLineTools/usr/bin/libtool: file: RT0.io is not an object file (not allowed in a library)
> > > >
> > > >
> > > > StAloneLlvmAsm
> > > > close, maybe just a config problem
> > > > m3llvm -b -d -o RT0.ib RT0.ic
> > > > llc -disable-fp-elim -filetype=asm -relocation-model=pic RT0.ib -o RT0.is
> > > > fg++ -m64 -arch x86_64 -c -x assembler RT0.is -o RT0.io
> > > > RT0.is:5:2: error: unknown directive
> > > >
> > > >
> > > > I assume we should ignore Int and Ext and focus on StAlone for now.
> > > >
> > > >
> > > > - Jay
> > > >
> > > >
> > > > _______________________________________________
> > > > M3devel mailing list
> > > > M3devel at elegosoft.com
> > > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> > > >
> > >
> > > --
> > > Rodney Bates
> > > rodney.m.bates at acm.org
> > > _______________________________________________
> > > M3devel mailing list
> > > M3devel at elegosoft.com
> > > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150914/1597ba82/attachment-0002.html>
More information about the M3devel
mailing list