[PATCH] Remove static initializers from MCSchedModel

[Pete Cooper]

> On Sep 2, 2014, at 9:57 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Fri, Aug 29, 2014 at 3:07 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
>> Still not sure why its better to make all of this public…
> Ultimately it was because tablegen couldn’t set the values of the private fields when it used the ‘x = { … }’ syntax.
> 
> So, I'll ask a question in complete ignorance because I don't understand how tablegen works. Please don't hold anything up based on this question, just hoping you'll enlighten me.
> 
> If there is a static method to return a local variable constructed with the correct defaults, and/or a default constructor which provides them, why can't TableGen produce that? I'm imagining TableGen emitting the "return Blah(X, Y, Z, ...);" statement.
Tablegen does actually construct a default model for targets which need it.  I think the only problem is getting that target specific model from say X86GenSubTargetInfo.inc to the target independent passes like Andy mentioned.  I’m happy to try figure out a way to do this.

If you’re curious, this is what X86 currently generates for its NoSchedModel.  Other targets are almost certainly the same.

static const llvm::MCSchedModel NoSchedModel = {
  MCSchedModel::DefaultIssueWidth,
  MCSchedModel::DefaultMicroOpBufferSize,
  MCSchedModel::DefaultLoopMicroOpBufferSize,
  MCSchedModel::DefaultLoadLatency,
  MCSchedModel::DefaultHighLatency,
  MCSchedModel::DefaultMispredictPenalty,
  0, // PostRAScheduler
  1, // CompleteModel
  0, // Processor ID
  0, 0, 0, 0, // No instruction-level machine model.
  nullptr}; // No Itinerary

> 
> That seems better than having a global at all, even if it is {} initialized as an aggregate.... But there is probably a reason why this can't be done. =]
Yeah, i’d like to avoid the { } constructor I have in the C++ code too.  Sounds tricky because of the target independent code, but maybe its possible.

Naively, we could wrap all MCSchelModel’s in the target independent passes in Optional, but then we’d have to have them not run the pass (or part of the pass perhaps) in the case where the model doesn’t exist.  That would be a change of behavior, but then maybe thats worth investigating?

Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140902/0109756a/attachment.html>