by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 04 04:14
    olprod15 added as member
  • Jun 04 04:14
    olprod11 added as member
  • Jun 04 04:14
    olprod4 added as member
  • Jun 04 04:14
    olprod16 added as member
  • Jun 04 04:14
    olprod12 added as member
  • Jun 04 04:14
    olprod13 added as member
  • Jun 04 04:14
    olprod2 added as member
  • Jun 04 04:14
    olprod3 added as member
  • Jun 04 04:14
    olprod added as member
  • Jun 04 04:14
    olprod5 added as member
  • Jun 04 04:14
    olprod1 added as member
  • Jun 02 15:44
    openpublishbuild added as member
  • Apr 10 17:47

    AndyAyersMS on master

    Fix links to Code of Conduct Merge pull request #1101 from t… (compare)

  • Apr 10 17:47
    AndyAyersMS closed #1101
  • Apr 10 16:50
    terrajobst opened #1101
  • Apr 03 17:14

    jkotas on master

    Link Code of Conduct (#1100) (compare)

  • Apr 03 17:13
    jkotas closed #1100
  • Apr 03 17:08
    terrajobst review_requested #1100
  • Apr 02 22:16
    terrajobst opened #1100
  • Aug 05 2019 00:15
    KodrAus opened #1099
Andy Ayers
@AndyAyersMS
@krytarowski yes we'd like to upstream as much as we can, but it takes time
Kamil Rytarowski
@krytarowski
Acknowledged. So, porting LLILC to NetBSD should be now straightforward. :smile:
Andy Ayers
@AndyAyersMS
Thanks for the fixes. Some of the other components we build out of the LLILC repo will be useful in getting CoreRT to work on NetBSD.
Kamil Rytarowski
@krytarowski
CoreRT already builds without patches on NetBSD. I just got LLILC to compile as well.. I had to disable -Werror for now, too many unused variables around. At the moment I will focus on small patches blocking build -- so one more patch to go to get it buildable and I will follow up with elimination of warnings.
Mukul Sabharwal
@mjsabby
@AndyAyersMS @JosephTremoulet Do you guys know if anybody internally (or externally) has gotten LLVM to run on Win10-ARM? I haven't tried, just trying to get a feeler if it's going to be work, I suspect not ...
Andy Ayers
@AndyAyersMS
@mjsabby I don't know, sorry
Big Jake
@jakesays
hey i have a need to translate .net assemblies in to llvm IL. would llilc be useful for such a task?
er, llvm ir
Andy Ayers
@AndyAyersMS
It could be, depends on what you are really trying to do. LLILC understands basic IL semantics fairly well.
pragmascript
@pragmascript
hello :) how does this project compare to .NET native?
Big Jake
@jakesays
@pragmascript iirc it will eventually be an open source alternative to the .net native compiler
@AndyAyersMS hey just noticed your response from the 29th. thanks.
Macaque Chen
@Samana
Hi! Haven't seen activities on this project for a couple of weeks... You guys taking a vacation? Or is it because of the merging of Xamarin? O_O
Andy Ayers
@AndyAyersMS
@Samana Most of us are now helping get RyuJit ready for the first official CoreCLR release....
Alex Forster
@alexforster
hey language team thought leaders: semi-off topic for this channel, but has a safe, low level GC-less systems language ever been considered? something with C# syntax plus the language features that make sense, with Rust-esque ownership/lifetime semantics
pragmascript
@pragmascript
This project seems to have disappeared from the roadmap: https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/
does this mean the project has been postponed/canceled?
Andy Ayers
@AndyAyersMS
@pragmascript on hold for now, jit team mostly focused for now on porting to more architectures (x86, arm64, arm32) in the old code base
pragmascript
@pragmascript
@AndyAyersMS ah, thanks for clarification
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
But still you can chip away on this project right?
Andy Ayers
@AndyAyersMS
Perhaps, but there are some big challenges that really need focused effort. GC and EH in particular.
Big Jake
@jakesays
hey any ARM experts around? i'm trying to figure out how to disable VFP and can't find any info on it. thought perhaps there might be an arm person around that might know.
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
When will work start again? When will this be production ready?
Russell C Hadley
@russellhadley
@sirinath , we don't have a date when this work will start up again. We're still consumed with some other milestones. And as to when this would get to a production ready release, that is currently not defined.
Demi Marie Obenour
@DemiMarie
@russellhadley what are those milestones? (Just wondering because currently C# is too slow for some tasks – that is the reason for some of the FCalls in System.String, for instance).
@russellhadley am I correct that the CoreCLR team does plan to finish LLILC?
Big Jake
@jakesays
hey is llilc dead?
kchoi
@choikwa
backlogged?
José Simões
@josesimoes
can please someone from the team update us on the current status of this project? any timeframe to get this rolling again?
I'm looking for support for small ARM processors and I'm willing to contribute
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
It will be good if this can be started again
Peter Tiedemann
@petertiedemann
Also wondering if this is completely dead, or just put on pause?
Michael Letterle
@mletterle
Same, tbh
Alexandre Rocha Lima e Marcondes
@arlm
sad to know it is stalled
hope it is just a little pause
Allan Lindqvist
@aL3891
yeah :/ wonder if its beeign merged into coreRT or something
Suminda Sirinath Salpitikorala Dharmasena
@sirinath
Has work started again?
Big Jake
@jakesays
hello...
will llilc ever see the light of day?
Phil Garcia
@tgiphil
Is this project dead?
Joseph Tremoulet
@JosephTremoulet

Quoting coreclr#4331 (comment):

As far as an LLVM based upper tier goes -- obviously we have looked into this to some extent with LLILC, and at the time we were in frequent contact with the Azul folks, so we are familiar with many of the things they were doing in LLVM to make it more amenable to compilation of languages with precise GC.

There were (and likely still are) significant differences in the LLVM support needed for the CLR versus what is needed for Java, both in GC and in EH, and in the restrictions one must place on the optimizer. To cite just one example: the CLRs GC currently cannot tolerate managed pointers that point off the end of objects. Java handles this via a base/derived paired reporting mechanism. We'd either need to plumb support for this kind of paired reporting into the CLR or restrict LLVM's optimizer passes to never create these kinds of pointers. On top of that, the LLILC jit was slow and we weren't sure ultimately what kind of code quality it might produce.

So, figuring out how LLILC might fit into a potential multi-tier approach that did not yet exist seemed (and still seems) premature. The idea for now is to get tiering into the framework and use RyuJit for the second-tier jit. As we learn more, we may discover there is indeed room for higher tier jits, or, at least, understand better what else we need to do before such things make sense.

Phil Garcia
@tgiphil
@JosephTremoulet Thanks for the update!
Macaque Chen
@Samana
@JosephTremoulet Thanks! How about the AOT part?
Renato Marinho
@renatomarinho
This message was deleted
SlimeQ
@SlimeQ
does llilc allow VS to produce LLVM bitcode files?
Renato Marinho
@renatomarinho
This message was deleted
3442853561
@3442853561
@SlimeQ I have the same question with you, does llilc allow ILAsm/MSIL to LLVM bitcode files or LLVM IR
Dmajster
@Dmajster
image.png
eyo, anyone seen this issue before?
trying to build CoreCLR
Ivan
@advancedwebdeveloper
any support for MIPS arch?