similar to: lld and thread over-subscription

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 12:55:20 PM > Subject: Re: lld and thread over-subscription > >

On Thu, Oct 1, 2015 at 10:55 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I honestly think that the ulimit of 1024 max threads is too strict for 48 > core machine. Processes are independent each other, so it is not strange > for them to spawn as many threads as the number of cores. What's the reason > you cannot increase the limit? > Yeah, this is

On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > We have a whole bunch of readers(we would have some more too), and was thinking if we should have a vector of Readers, and have a function isMyFormat in each of them. > > Any reader that knows to handle, goes ahead and parses the file. > > On a side note, we currently use .objtxt as an figure

Hi, We have a whole bunch of readers(we would have some more too), and was thinking if we should have a vector of Readers, and have a function isMyFormat in each of them. Any reader that knows to handle, goes ahead and parses the file. On a side note, we currently use .objtxt as an figure out if the file is a YAML file or not. I have added FIXME's in the code, if we could some kind of

Folks, I'm having a look at LLD and I need some guidance... I know it's not production ready for x86 and ARM (the idea is to make it so). My steps: I've added it to tools/lld and ran CMake again (on x86_64) on a standard release build (static linking). It works, builds but I see one unit test error: Note: Google Test filter = InputGraphTest.Observer [==========] Running 1 test from

I had a similar issue with arm vs thumb in mach-o. Each function’s thumbness is marked in its symbol table entry. But it is even worse, a function could change encoding in the middle (only hand coded assembly could do this). My solution was to add a new Reference Kind for mach-o which is the current instruction encoding. The offsetInAtom() is the offset where the encoding kind changes.

On 10/9/2013 3:09 PM, Nick Kledzik wrote: > On Oct 9, 2013, at 11:23 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: >> We have a whole bunch of readers(we would have some more too), and was thinking if we should have a vector of Readers, and have a function isMyFormat in each of them. >> >> Any reader that knows to handle, goes ahead and parses the file.

On Nov 11, 2014, at 11:54 AM, Rui Ueyama <ruiu at google.com> wrote: > This falls into the usual topic that whether or not we should have a generic map attached to an atom. You used a reference as an alternative for the map in this case but the basic idea is the same. > > Although using a reference would be practical, it still feels a hack to me. It's awkward at least. Why

I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \

On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > That sounds quite reasaonable; how does one usually go about doing that? a repro zip that hits both asserts? > You can take inspiration from anything in lld/test, but basically either an assembly source (or multiple) passed through llvm-mc and then lld, or a YAML file passed to yaml2obj

Michael, To validate the refactor of YAML Reader/Writer using YAML I/O. I updated all the test cases to be compatible with YAML I/O. One issue that was a gnarly was how to handle the test cases with archives. Currently, we have test cases like: --- atoms: - name: foo # more stuff --- archive: - name bar.o atoms: - name: bar # more stuff This sort of

On Thu, Sep 27, 2018 at 3:12 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Sep 27, 2018 at 2:42 PM Armando Montanez via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Since the goal is to start llvm-tapi more or less from scratch, I feel >> the best approach initially is to focus on the structure as a key >> point of

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Regardless of any of that, given that TBD files _are_ an integral part > of the apple platform, supporting them is certainly a necessity in order to > have a working apple linker. So, if making LLD work for Apple/MachO is the > justification for adding TBD support to LLVM, that

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

Hi Nick, I had a few questions :- 1) Is there a way to validate that the input file is of a valid format, thats defined by the YAML Reader ? 2) How are you plannning to represent section groups in the YAML ? 3) How are you planning to support Atom specific flags ? Is there a way already ? (This would be needed to group similiar atoms together) 4) Are you planning to support representing

Sorry, I was thinking to review the test but didn't. Is this test complete? It does invoke lld, but it didn't verify its output. On Mon, Jul 30, 2018 at 2:03 PM Andrew Kelley <superjoe30 at gmail.com> wrote: > Ping Rui. Is there anything else that needs to be done on this patch? > > On Tue, Jul 17, 2018 at 6:58 AM, Carlo Kok via llvm-dev < > llvm-dev at

Got it. Attached are both the testcase & the fix. On Tue, Jul 17, 2018, at 12:06, Carlo Kok via llvm-dev wrote: > On Wed, Jul 11, 2018, at 16:45, Davide Italiano wrote: > > On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > > > That sounds quite reasaonable; how does one usually go about doing that?

Benifits of TBD: 1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI. 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK 3) Stubs are producible from TBDs (or should be)

On 10/9/2013 4:19 PM, Shankar Easwaran wrote: > On 10/9/2013 3:09 PM, Nick Kledzik wrote: >> On Oct 9, 2013, at 11:23 AM, Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> We have a whole bunch of readers(we would have some more too), and >>> was thinking if we should have a vector of Readers, and have a >>> function isMyFormat in each