<div dir="ltr">Regarding pointers going away, that looks really good to me, but Andy should make that call -- i've never touched most of this code.<div><br></div><div>One minor note there:</div><div><div> /// getSchedModelForCPU - Get the machine model of a CPU.</div>
<div> ///</div><div>- const MCSchedModel *getSchedModelForCPU(StringRef CPU) const;</div><div>+ MCSchedModel getSchedModelForCPU(StringRef CPU) const;</div><div> </div><div> /// getSchedModel - Get the machine model for this subtarget's CPU.</div>
<div> ///</div><div>- const MCSchedModel *getSchedModel() const { return CPUSchedModel; }</div><div>+ MCSchedModel getSchedModel() const { return CPUSchedModel; }</div></div><div><br></div><div>These seem like they might be better as const references? At least the last one. I might have missed other places where the same is true, not sure.</div>
<div><br></div><div>On some of the details:</div><div><br></div><div><div>@@ -191,7 +188,6 @@ public:<br></div><div> </div><div> bool CompleteModel;</div><div> </div><div>-private:</div><div><br></div><div>Still not sure why its better to make all of this public...</div>
<div><br></div><div><br></div><div>@@ -201,37 +197,6 @@ private:<br></div><div> friend class InstrItineraryData;</div><div> const InstrItinerary *InstrItineraries;</div><div> </div><div>-public:</div><div>- // Default's must be specified as static const literals so that tablegenerated</div>
<div>- // target code can use it in static initializers. The defaults need to be</div><div>- // initialized in this default ctor because some clients directly instantiate</div><div>- // MCSchedModel instead of using a generated itinerary.</div>
<div>- MCSchedModel(): IssueWidth(DefaultIssueWidth),</div><div>- MicroOpBufferSize(DefaultMicroOpBufferSize),</div><div>- LoopMicroOpBufferSize(DefaultLoopMicroOpBufferSize),</div><div>
- LoadLatency(DefaultLoadLatency),</div><div>- HighLatency(DefaultHighLatency),</div><div>- MispredictPenalty(DefaultMispredictPenalty),</div><div>- PostRAScheduler(false), CompleteModel(true),</div>
<div>- ProcID(0), ProcResourceTable(nullptr),</div><div>- SchedClassTable(nullptr), NumProcResourceKinds(0),</div><div>- NumSchedClasses(0), InstrItineraries(nullptr) {</div>
<div>- (void)NumProcResourceKinds;</div><div>- (void)NumSchedClasses;</div><div>- }</div><div><br></div><div>Can you keep the default constructor and such now that you're not creating globals at all?</div><div>
<br></div><div>-</div><div>- // Table-gen driven ctor.</div><div>- MCSchedModel(unsigned iw, int mbs, int lmbs, unsigned ll, unsigned hl,</div><div>- unsigned mp, bool postRASched, bool cm, unsigned pi,</div>
<div>- const MCProcResourceDesc *pr, const MCSchedClassDesc *sc,</div><div>- unsigned npr, unsigned nsc, const InstrItinerary *ii):</div><div>- IssueWidth(iw), MicroOpBufferSize(mbs), LoopMicroOpBufferSize(lmbs),</div>
<div>- LoadLatency(ll), HighLatency(hl),</div><div>- MispredictPenalty(mp), PostRAScheduler(postRASched),</div><div>- CompleteModel(cm), ProcID(pi),</div><div>- ProcResourceTable(pr), SchedClassTable(sc), NumProcResourceKinds(npr),</div>
<div>- NumSchedClasses(nsc), InstrItineraries(ii) {}</div><div>-</div><div> unsigned getProcessorID() const { return ProcID; }</div><div> </div><div> /// Does this machine model include instruction-level scheduling.</div>
<div>@@ -258,6 +223,44 @@ public:</div><div> assert(SchedClassIdx < NumSchedClasses && "bad scheduling class idx");</div><div> return &SchedClassTable[SchedClassIdx];</div><div> }</div><div>
+</div><div>+ // /\brief Returns a default initialiszed mdoel. Used for unknown processors.</div><div>+ static MCSchedModel GetDefaultSchedModel() {</div><div>+ return { DefaultIssueWidth,</div><div>+ DefaultMicroOpBufferSize,</div>
<div>+ DefaultLoopMicroOpBufferSize,</div><div>+ DefaultLoadLatency,</div><div>+ DefaultHighLatency,</div><div>+ DefaultMispredictPenalty,</div><div>+ false,</div>
<div>+ true,</div><div>+ 0,</div><div>+ nullptr,</div><div>+ nullptr,</div><div>+ 0,</div><div>+ 0,</div><div>+ nullptr</div><div>+ };</div>
<div>+ }</div><div><br></div><div>I still find the default constructor somewhat cleaner than this... but it's not a huge deal either way.</div><div><br></div><div>+</div><div>+ /// \brief Returns true if this model is the default,</div>
<div>+ bool isDefaultModel() const {</div><div>+ const MCSchedModel Default = GetDefaultSchedModel();</div><div>+ return IssueWidth == Default.IssueWidth &&</div><div>+ MicroOpBufferSize == Default.MicroOpBufferSize &&</div>
<div>+ LoopMicroOpBufferSize == Default.LoopMicroOpBufferSize &&</div><div>+ LoadLatency == Default.LoadLatency &&</div><div>+ HighLatency == Default.HighLatency &&</div>
<div>+ MispredictPenalty == Default.MispredictPenalty &&</div><div>+ PostRAScheduler == Default.PostRAScheduler &&</div><div>+ CompleteModel == Default.CompleteModel &&</div>
<div>+ ProcID == Default.ProcID &&</div><div>+ ProcResourceTable == Default.ProcResourceTable &&</div><div>+ SchedClassTable == Default.SchedClassTable &&</div><div>+ NumProcResourceKinds == Default.NumProcResourceKinds &&</div>
<div>+ NumSchedClasses == Default.NumSchedClasses &&</div><div>+ InstrItineraries == Default.InstrItineraries;</div><div>+ }</div></div><div><br></div><div>Maybe in a separate patch, but it would seem cleaner to define a generic operator== for the class, and then just compare against the default here.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 2:26 PM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@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 style="word-wrap:break-word"><br><div><div class=""><blockquote type="cite"><div>On Aug 29, 2014, at 2:18 PM, Andrew Trick <<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>> wrote:</div>
<br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<blockquote type="cite"><div><br>On Aug 29, 2014, at 2:14 PM, Pete Cooper <<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>On Aug 29, 2014, at 2:10 PM, Andrew Trick <<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>> wrote:<br><br><br><blockquote type="cite">On Aug 29, 2014, at 9:38 AM, Pete Cooper <<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>> wrote:<br>
<br>Hi all<br><br>Please review this patch to change MCSchedModel to avoid static initializers. This makes it behavior match other structs with similar uses, e.g., MCWriteProcResEntry and MCProcResourceDesc.<br><br>This is part of the work to remove all the static initializers from LLVM.<br>
</blockquote><br><br>Great. I can’t remember why we needed a default ctor on MCSchedModel any more. If we can get away with constant static initialization it’s much better.<br><br>I would define an LLVM_DELETED_FUNCTION default ctor to make sure we’re not silently breaking some target.<br>
<br>LGTM.<br></blockquote><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Thanks Andy. I’ll add the deleted constructor.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I’m preparing an updated patch now based on Chandler’s feedback so that we can see how we want to proceed with this.</span><br>
</div></blockquote><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Unfortunately, I don’t think the “delete” keyword will work because you can’t define a default ctor if you want to initialize it with an initializer list. Maybe someone who knows C++11 rules has an idea for how to catch default ctor uses.</div>
</div></blockquote></div>Yeah, i’m not sure how to do that either.<div class=""><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Or you could just do an experiment where you delete the default ctor without changing the initialization and make sure all targets still build. That would be good enough for me.</div></div></blockquote></div>Experiment done. Everything builds with the attached patch.</div>
<div><br></div><div>For some details as to how this differs from before. I changed it from a static field to a function to return a default initialized model. Unfortunately this requires more source changes as now we can’t have pointers to the default model. In fact cleaning this up basically removes pointers to MCSchedModel from all the compiler. </div>
<div><br></div><div>Perhaps this is what we want. I’m open to discuss whether this is a good idea.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Pete</div><div><br></div><div></div></font></span></div>
<br><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
-Andy</div></div></blockquote></div><br></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>