<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">IMHO the right way to handle target function attributes is to re-initialize the target machine and TTI for every function (if the attributes changed). Do you have another solution in mind ?</blockquote></div><br>I don't really understand this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">TargetMachine and TTI may be quite expensive to initialize. </div></div></div></blockquote><div><br></div><div>Yes. But we can keep a few TMs around and only initialize TTI, which should be inexpensive to initialize because it has no state. </div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">Doing so for each (sometimes tiny) function processed doesn't make a lot of sense to me.</div></div></div></blockquote><div><br></div><div>I assume that even for LTO builds, the target attributes won't change very often. </div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">Wouldn't it be better to design a TargetMachine (and TTI, or other passes that are similar) which provides context-sensitive answers? You could imagine this being a wrapper which delegates to one of two real TM and TTI implementations based on a mode switch.</div></div></div></blockquote><div><br></div><div>This can work, but I don't have enough information about two things: </div><div>1. How often do we switch TMs. (and how expensive it is)</div><div>2. How complex is it to create a wrapper and what overhead is the wrapper going to add. </div><div><br></div><div>Do you have a design in mind for such a wrapper ?</div><div><br></div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">Alternatively, we could look at partitioning functions into two modules, and then bring up the infrastructure once per module.</div></div></div></blockquote><div><br></div>I am not sure if this can work. I see a scenario where a non-AVX function can call an AVX functions. Splitting these into two modules can potentially prevent some optimizations. <br><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">I would personally choose between these based on how much shared functionality there would be in the TM and TTI between the two.</div></div></div></blockquote></div><br></body></html>