<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 3:51 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2015 Jun 17, at 15:44, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Jun 17, 2015 at 2:15 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
><br>
> > On 2015 Jun 17, at 14:03, Alex L <<a href="mailto:arphaman@gmail.com">arphaman@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > 2015-06-17 13:52 GMT-07:00 Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>>:<br>
> ><br>
> > > On 2015 Jun 17, at 13:20, Alex Lorenz <<a href="mailto:arphaman@gmail.com">arphaman@gmail.com</a>> wrote:<br>
> > ><br>
> > > Hi dexonsmith, bob.wilson, bogner,<br>
> > ><br>
> > > This patch moves the SlotTracker class out of AsmWriter.cpp into a separate module that's publicly accessible.<br>
> > ><br>
> > > This patch would be useful for MIR Serialization, in particular it would enable the MIR parser to parse metadata machine operands. The metadata machine operands are serialized using the familiar '!' <slot> notation, and the MIR parser has to be able to map from slot numbers to the actual metadata nodes. The SlotTracker class would allow the MIRParser to create this mapping.<br>
> ><br>
> > I can see that this would be useful for *writing* .mir files, but I<br>
> > don't think you can safely use this for *reading* .mir files.<br>
> ><br>
> > Metadata slots can be assigned arbitrarily in an LLVM IR file, such as:<br>
> ><br>
> >     !named = !{!36, !72}<br>
> >     !72 = !{!"string"}}<br>
> >     !36 = !{!72, !{!{}}}<br>
> ><br>
> > If you were to parse the module and then run the slot tracker, you'd get:<br>
> ><br>
> >     !named = !{!1, !2}<br>
> >     !1 = !{!2, !3}<br>
> >     !2 = !{!"string"}<br>
> >     !3 = !{!4}<br>
> >     !4 = !{}<br>
> ><br>
> > or something close to that.<br>
> ><br>
> > You couldn't safely take an already-parsed Module, run the slot-tracker<br>
> > on it, and then parse machine functions that referenced metadata.  But<br>
> > it sounds like that's what you're suggesting?<br>
> ><br>
> > This makes sense, yeah this patch wouldn't really work then.<br>
> ><br>
> ><br>
> > Instead, I think you need to:<br>
> ><br>
> >  1. Yes, surface the slot tracker (exactly this patch), but for completely<br>
> >     different reasons:  so that you can write out correct metadata numbers<br>
> >     for metadata references within machine functions, to match the metadata<br>
> >     that you wrote out for the LLVM IR.<br>
> >  2. Use (1) so that the same slots are used when writing LLVM IR portion of<br>
> >     MIR as the machine functions.<br>
> ><br>
> > I don't need to surface the slot tracker then, as I can print out the correct metadata slot numbers by printing the metadata nodes as operands. They create the slot tracker and initialize it for the whole module, so the correct slot numbers are printed.<br>
><br>
> Oof, that sounds expensive.  Actually, I know it is: I made it expensive,<br>
> since previously it was just about useless :).<br>
><br>
> This'll be fine for hand-written testcases, but if someone is debugging<br>
> some crash from a big input, the MIR will take O(N^2) to print (needs to<br>
> make slots for all metadata every time something prints out a metadata<br>
> machine operand).<br>
><br>
> Given that the main goal right now *is* testcases, maybe this is okay,<br>
> but please add a FIXME to make it efficient as a follow-up.<br>
><br>
> FWIW, llvm-diff has the same problem (which makes it nearly useless for LTO issues). Maybe we could have some way for the module to cache this, with the proviso that you must not further modify the module without invalidating the result?<br>
><br>
> -- Sean Silva<br>
<br>
</div></div>I think that would be too bug prone.  Lots of passes dump things out in<br>
DEBUG statements before/after making changes.<br></blockquote><div><br></div><div>I wasn't talking about that being the only way. Just that it would be a useful API for those times when you know you are going to be doing a lot of printing and no modifying. It's basically the same thing as explicitly passing a slottracker (your 2.), but less invasive. If the slottracker on the module is not "pledged to be ok to use", then it falls back to recomputing as it currently does. Also, tracking it on the module has the benefit that it might be possible to add a debugging check for mutating operations to check that the cached slottracker is not marked as ok to use.</div><div><br></div><div>I think that explicitly passing in a slottracker is all-around better though as long as it doesn't cause a huge amount of churn.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But there are some ideas I had a while ago that I never followed up on:<br>
<br>
 1. Add API for a "lazy" numbering, which assigns slots in the order<br>
    slots are requested.  This would make the numbering self-consistent<br>
    within a given dump, but incomparable between separate dumps.<br>
 2. Add API for passing in a SlotTracker.  Caller is in charge of only<br>
    passing in the same slot tracker if it's still going to be valid.<br>
<br>
Note that #2 easily solves the problem in MIR.  The trick is making it<br>
easy to use elsewhere.</blockquote></div><br></div></div>