<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">For this particular case, I don't think having a split function is<br></span><span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">particularly interesting.</span></blockquote><div><br></div><div>I agree that conceptually all disjoint ranges are the same. Until they are not: I haven't looked closely at the code changes but it's easy to introduce assumptions about the layout hierarchy (range->function->segment->section->module)</div><div><br></div><div>Even if the code doesn't do this today it seems a good idea to have check to catch attempts to introduce such assumptions in the future. </div><div>If these are intended to be regression tests it seems even more important to do so.</div><div><br></div><div>Also, for either regression on integration tests I think it's a good idea to include the common real world cases in addition to synthetic test cases.</div><div><br></div><div>That being said, these are just some drive-by comments and I'm not opposed to getting this change in.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 8, 2018 at 12:23 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ahh sorry, I jumped in kinda late and the thread was already quite long so I didn’t read everything.  It would probably be some overhead to learn how to write the asm files but you can probably have clang-cl generate one for you and just move the directives around <br><div class="HOEnZb"><div class="h5"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 8, 2018 at 12:18 PM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 8 Jun 2018 at 19:58, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, Jun 8, 2018 at 11:52 AM Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br>
>><br>
>> On Fri, 8 Jun 2018 at 18:48, Leonard Mosescu <<a href="mailto:mosescu@google.com" target="_blank">mosescu@google.com</a>> wrote:<br>
>> ><br>
>> > To me, a linker order file (of any linker) sounds like a good<br>
>> abstraction level for generating that kind of input (on linux, I might<br>
>> have preferred a .s file with hardcoded .loc directives, but that<br>
>> doesn't seem to be a thing on windows).<br>
><br>
><br>
> Why not?  I think that would work fine (it’s called .cv_loc in codeview though)<br>
<br>
Because I didn't know that's possible? :D<br>
<br>
I dropped a remark about .s files several pages back but noone picked<br>
it up, so I assumed it's infeasible for some reason. If that is the<br>
case, then this really sounds like a good idea. This way we should be<br>
even able to generate the split function without relying on PGO or<br>
checked-in binaries.<br>
</blockquote></div>
</div></div></blockquote></div><br></div>