search for: ributzka

...e Mach-O TAPI > code? > > > > Thanks, > > Shoaib > > > > *From: *Shoaib Meenai <smeenai at fb.com> > *Date: *Wednesday, March 6, 2019 at 9:22 PM > *To: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> > *Cc: *"juergen at ributzka.de" <juergen at ributzka.de>, Hans Wennborg < > hans at chromium.org> > *Subject: *What's the status of Mach-O TAPI? > > > > Hi all, > > > > It looks like Juergen landed the TextAPI libraries for Mach-O in > https://reviews.llvm.org/D53945, and...

...sure if the entire deletion was intentional, since the commit message only mentions reverting a certain series of patches; CC Hans. In any case, I'm wondering if there are plans to revive it, since the existing open source drops (https://opensource.apple.com/source/tapi/ and https://github.com/ributzka/tapi) are somewhat outdated. Thanks, Shoaib -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190307/8fe9bf26/attachment.html>

...We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG co...

On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com> wrote: > I see. We still can use that shortcut to catch the simple case after type > legalization, but we could also do a more elaborate type check before type > legalization to enable it? > If you're going to write the code to check the types anyway,...

Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com<mailto:juergen at apple.com>> wrote: I see. We still can use that shortcut to catch the simple case after type le...

Hi @ll, a few of us had recently a discussion about how to manage the C API and possible policies regarding addition, maintenance, deprecation, and removal of API. Even thought there is a strong agreement in the community that we shouldn't break released C API and should be backwards compatible, there doesn’t seem to be a developer policy that backs that up. This is something we should fix.

...uess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake; > > set(LLVM_PLUGIN_EXT ${CMAKE_SHARED_MODULE_SUFFIX}) > > Does it have expected value? > > 2014-02-13 10:11 GMT+09:00 Juergen Ributzka <juergen at apple.com>: >> Hi Takumi, >> >> I am not sure if it this change, but recently we started to build >> LLVMHello.so and BugpointPasses.so on OS X. A few bugpoint tests are >> failing, because they are looking for a dylib that doesn't exist. >&gt...

...o take advantage of it too and extend its functionality to other object file formats. I initially developed the project as a CLANG project, but that was mostly for practical reasons (out-of-tree development, separate repo, etc). For the curious ones I pushed the repo to github (https://github.com/ributzka/tapi <https://github.com/ributzka/tapi>). I imagine, for example, that the reading/writing of TBD files is something that would fit better into the LLVM sources, which makes it available to other libraries and tools (e.g. LLVMObject, llvm-nm, lld, ...). I created a small patch that integrat...

Hi @ll, I would like to obsolete and completely remove the WebKit Calling Convention. The CC was originally added for FTL and there are no other users I am aware off. Since WebKit moved away from LLVM a while ago I don’t see the need to keep the dead code around anymore. Please let me know if anyone happens to use this calling convention or has any objection with removing it. Thanks Cheers,

...vm tools can read or even write files from/for OSX should be fairly non-controversial so how about go ahead and do that first (I'll happily review if you'd like) and then we can go from there to do anything else with TAPI and llvm? Sound good? -eric On Thu, Sep 7, 2017 at 5:01 PM Juergen Ributzka via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi @ll, > > Over the past years I have been looking into how to reduce the size of the > SDK that ships with Xcode and how to improve build times for the overall OS > inside Apple. The result is a tool called TAPI, which is use...

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill fl...

Hi @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don’t run the X86 DAG combiner before Type

On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine > in the X86 backend. This defers all VSELECT related DAG combines until > after the Legalizer has run. If the IR has already only legal types the > second...

...com <mailto:grosbach at apple.com>> wrote: >> >> >>> On Jul 20, 2015, at 1:45 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >>> >>> >>> >>> On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: >>> Wow, this went of topic very quickly ;-) >>> >>> >>> It did. I am sorry about that :) >>> >>> As you know I am very interested in an stable API (C and/or C++) for LL...

On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> wrote: > I also misunderstood your original transition proposal in this point. I > agree with Jim that we should keep the current C-API where it is and have a > separate location for the bindings. I envision that we will need the > current C-API and the new...

...:20 PM Jim Grosbach <grosbach at apple.com> wrote: > On Jul 20, 2015, at 2:24 PM, Jim Grosbach <grosbach at apple.com> wrote: > > > On Jul 20, 2015, at 1:45 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> Wow, this went of topic very quickly ;-) >> >> > It did. I am sorry about that :) > > >> As you know I am very interested in an stable API (C and/or C++) for >> LLVM, but maybe we should discuss this in a separa...

Sounds good. Lets get started by nailing down the C API and semantics for this first. I mirrored the C API for the LLVM context diagnostic handler and used Andy’s suggested name for the callback. The opaque handle was suggested by Duncan and can provide optional user specified information that is provided back during the callback (i.e. barrier, etc). Cheers, Juergen Core.h: typedef void

...patible with future versions of LLVM. That's an unsolved problem. We should stick with what we have. The only thing we can do to keep LLVM flexible is to limit the set of new things we expose over the C API boundary, which I'm totally in favor of. On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > a few of us had recently a discussion about how to manage the C API and > possible policies regarding addition, maintenance, deprecation, and removal > of API. > > Even thought there is a strong agreement in the community that...

On Wed, Jul 29, 2015 at 3:28 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> I also misunderstood your original transition proposal in this point. I >> agree with Jim that we should keep the current C-API where it is and have a >> separate location for the bindings. I envision that we will need the >>...

Sounds good. I will add that to the StackMap documentation when I update it for v2. —Juergen > On Jul 10, 2015, at 9:40 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > No, but I've noticed that it is true in practice, and so I think that we should say something about it one way or another. Especially since, in switching to a fixed-size record format, binary searching now