search for: layoutpasses

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

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,

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....

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,

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

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

+llvmdev On Fri, Mar 21, 2014 at 3:43 PM, Rui Ueyama <ruiu at google.com> wrote: > Hi all, > > I'm trying to debug an issue that LLD sometimes get into an infinite loop > in setChainRoot() in LayoutPass.cpp. It looks like the cause is either > buildPrecededByTable() handles layoutBefore edges in a wrong way or we > construct a contradictory layout-before/layout-after

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

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, It looks like the the ELFPassFile doesnot get an ordinal value assigned, as its added in a pass. Is there a way to assign a file ordinal for the files added by Passes ? Till that time, I am going to XFAIL the ifunc test. More tests should fail, and am not sure why they are not failing. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted

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 ordinal and each atom would get an ordinal too, after the below problem is fixed. Thanks Shankar Easwaran On 10/6/2013 10:54 PM, Shankar Easwaran wrote: > Hi, > > It looks like the the ELFPassFile doesnot get an ordinal value > assigned, as its

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 Mon, Oct 7, 2013 at 11:51 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > 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 ? > That API may work, but I don't think you always want to assign the largest file ordinal for a file created in