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 doLayoutAfter, doInGroup. Any concerns on sub-classing ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140327/e57f379f/attachment.html>
Existing reference kinds, namly layout-before (until it's removed), layout-after and in-group, have clear semantics that is already implemented in the layout pass. For example, hen you create a reference from atom A to B with a layout-after reference, B will be always placed after A. Allowing users to redefine such basic relationship is more confusing than good. It's like redefining an operator, so caution needed. Do you have any immediate need to subclass it? Because we have the entire codebase, we can add such abstraction when we need it, so doing it beforehand for future possible use tend to be overdesigning stuff. On Thu, Mar 27, 2014 at 8:57 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:> 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 doLayoutAfter, > doInGroup. > > Any concerns on sub-classing ? > > Thanks > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140327/53c11972/attachment.html>
Hi Rui, I think flavors would use only a subset of the reference kinds that are available. There is no need to spin in a reference kind, which doesnot find any atom. For example, I am not sure if MachO/COFF have weak symbols,the current layout passes are very generic and if the usecase is not relevant, we can curtail those passes in the subclasses as well. This could simplify and could achieve good speed up too. Thanks Shankar Easwaran On 3/27/2014 1:24 PM, Rui Ueyama wrote:> Existing reference kinds, namly layout-before (until it's removed), > layout-after and in-group, have clear semantics that is already > implemented in the layout pass. For example, hen you create a > reference from atom A to B with a layout-after reference, B will be > always placed after A. Allowing users to redefine such basic > relationship is more confusing than good. It's like redefining an > operator, so caution needed. > > Do you have any immediate need to subclass it? Because we have the > entire codebase, we can add such abstraction when we need it, so doing > it beforehand for future possible use tend to be overdesigning stuff. > > On Thu, Mar 27, 2014 at 8:57 AM, Shankar Easwaran > <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote: > > 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 doLayoutAfter, > doInGroup. > > Any concerns on sub-classing ? > > Thanks > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation > >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140327/d7807cf2/attachment.html>