[M3devel] Assert problem

Rodney M. Bates rodney_bates at lcwb.coop
Wed Oct 25 17:40:29 CEST 2017



On 10/22/2017 08:56 PM, Peter McKinna wrote:
> Oh and a couple of other things.
>
> I hadn't tried commands, very useful.
>
> Running cm3 -O to optimise to O2 our only optimisation level sets O0 in llc, in effect removing optimisation.
> (I don't know why we cant replicate gcc and llvm on some of these command line options ie having O0 O1 O2 etc which get passed to the backend)
>

Yes, we should do this.  It could force somebody to update some existing scripts with
different options, but probably not too big a problem, if we communicate it well.

> I've installed llvm version 5.0 and built a set of swig based bindings for DIBuilder, only partially tested. I could put on github in a directory dibindings ?? under llvmbindings and you could evaluate and see if its worth using. The benefit is that it's quite easy to upgrade the bindings when they change versions. Or I could email a tarball.
>

That would be great.  How about a directory named something like m3-sys/llvm5.0bindings?  When we first
went to git, I tried out git branches, but found it almost impossible to be able to look at
diffs between branches, something I need to do often.  It seems git will only check out one
branch at a time into one's working directory, removing the previous branch in the process.
In any case, since m3llvm is a separate executable and llvmbindings is a separate library,
it seems like having multiple versions in different subdirectories in the same branch should
not create problems.

Then we could create m3-sys/llvm5.0 for the m3llvm version to use llvm5.0bindings.
There was discussion in the llvm mailing list of significant reorganization of
DIBuilder's type hierarchy, affecting the API, so probably all the DIBuilder
calls in m3llvm will need review and some of them changed.  I think this will
probably be a change for the better, in producing debug info.

> We should probably upgrade to llvm 5.0. There are lots of bugfixes and I'd like to test their 128 bit floating point stuff in the hope of changing EXTENDED to use it someday, assuming its easy to change the gcc backend at the same time. I think they have changed the C api again judging by the release notes so the m3 interface will need updating.
>
> Regards Peter
>

-- 
Rodney Bates
rodney.m.bates at acm.org


More information about the M3devel mailing list