similar to: [LLVMdev] LLD: Layout-after and layout-before

Thank you for quick responses! As to dead stripping, if dead stripping is the only pass we need bi-directional edges, we might want the dead stripping pass to construct internal data structure by reversing the graph to construct layout-before edges from layout-after edges. This should be less error prone than maintaining two reverse-directional edges throughout all passes. Of course it will make

In r226336 I shove off 1.2 seconds out of 9.8 seconds for lld to link lld. That's done by parallelizing archive member parsing. But I realized that was not the slowest pass. The single slowest pass in LLD is LayoutPass. Only sort() at the last of Layoutpass::perform takes about 3 seconds (one third of total execution time). It is because the comparison function passed to sort, compareAtoms,

Hi, It looks like the COFF reader creates an Alias atom by adding a kindLayoutAfter reference to the target atom. Now since the kindLayoutAfter passes are moved to machO how does it still work ? Does it work by chance because of ordinals ? I would think moving kindLayoutAfter references and having the LayoutPass would be a better choice. Shankar Easwaran -- Qualcomm Innovation Center,

Hi, I think we are overloading the Layout references for garbage collection. If you are creating a reference (kindLayoutAfter) from A to B, that may not mean that you cannot garbage collect B for the end user. My thought on Layout references was that it only guarantees that atoms appear in Layout reference order. Why are we overloading this for Garbage collection (aside from saving space/code)

Hi, I think it would be great if we could subclass the LayoutPass. All the generic functionality could be in the parent to run the layout-after/in-group/ and currently the layout-before passes(until it gets removed). Flavors can *choose to run the layout passes* that they use and determine the way things get ordered in the layout pass. The compare function in the LayoutPass would call

I've run a new scan of LLD's architecture and it appears to be getting cleaner! There are still some upward dependencies however: - core depends on Reader and Writer - passes depend on Reader and Writer - ReaderWriter/PECOFF/ReaderCOFF.cpp depends on Driver.h The updated architecture can be seen here: http://www.c2lang.org/docs/lld_architecture_20140710.png On Tue, Jun 3, 2014 at 3:07

Well, it does have a Registry& that's defined in Reader.h. But that can be forward declared (and apparently is in some of the other headers it includes. On Thu, Jul 10, 2014 at 12:08 PM, Andreas Wendleder < andreas.wendleder at googlemail.com> wrote: > Hi > > - passes depend on Reader and Writer >> > > That's an easy one. Compile tested on Windows with

Yes, but if you look in LayoutPasses.c, it calls registry.referenceKindToString(..), so it does need the definition.. On Thu, Jul 10, 2014 at 2:30 PM, Jean-Daniel Dupas <mailing at xenonium.com> wrote: > Using forward-declaration would not fix the layer violation. > > Le 10 juil. 2014 à 13:10, Bas van den Berg <b.van.den.berg.nl at gmail.com> > a écrit : > > Well,

On Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote: > If you attach two ore more symbols along with offsets to a chunk of data, > it would be a pretty similar to a section. That means that if you want to > do something on the atom model, now you have to treat the atoms like > sections. > What do you lose/pay by having to treat the atoms like sections?

Ping ? Do you think that we need to have an API in LinkingContext to return the next ordinal available, so that files created by passes can be assigned ordinals ? Thanks Shankar Easwaran On 10/6/2013 11:07 PM, Shankar Easwaran wrote: > In addition I think the LayoutPass std::stable_sort be replaced with > std::sort as total ordering is guaranteed as each File would get an >

On Fri, May 1, 2015 at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, May 1, 2015 at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > Caveat Why not define a section as an atom and keep using the atom > model? If > > we do this, we would have to allow atoms to have more than one name. Each > > name would have an offset in the atom (to

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write

I guess I'm talking about atoms. Do we have notion of section in LLD? On Wed, Mar 25, 2015 at 8:35 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 3/24/2015 7:51 PM, Rui Ueyama wrote: > >> On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com>

I think no one is opposing the idea of reading and writing YAML. The problem here is that why we need to force all developers to write code to serialize intermediate data in the middle of link, which no one except the round-trip passes needs. On Fri, Feb 6, 2015 at 6:41 PM, Shankar Easwaram <shankarke at gmail.com> wrote: > Doing it for every input file is not useful as some of the

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

On Fri, Feb 6, 2015 at 5:42 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, Feb 6, 2015 at 5:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > There are two questions. > > > > Firstly, do you think the on-disk format needs to compatible with a C++ > > struct so that we can cast that memory buffer to the struct? That may be > >

On Fri, May 29, 2015 at 6:01 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, May 29, 2015 at 1:14 AM, Rui Ueyama <ruiu at google.com> wrote: > >> I want to make it clear that I didn't (at least intend to) compromise >> flexibility or beauty of design with short-term performance gain. I was >> trying to do simple things in a simple way

Hi guys, After working for a long period of time on LLD, I think I found a few things that we should improve in the LLD design for both development ease and runtime performance. I would like to get feedback on this proposal. Thanks! *Problems with the current LLD architecture *The current LLD architecture has, in my opinion, two issues. *The atom model is not the best model for some architectures

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part

On Tue, Mar 24, 2015 at 5:40 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Mar 24, 2015, at 5:09 PM, Rui Ueyama <ruiu at google.com> wrote: > > > It's not a big deal, but it always annoyed me a bit when I hit it, so > I'll bring it up here. > > > > LLD represents an alignment X as log2(X) in some places and just X in > other places.