[M3devel] LLVM builder modes Int/Ext/StAlone

Jay K jay.krell at cornell.edu
Sun Sep 13 01:50:08 CEST 2015


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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150912/4ac2c37b/attachment-0002.html>


More information about the M3devel mailing list