<div dir="ltr"><div class="gmail_default" style>I know, I said a bad word -- analysis group.</div><div class="gmail_default" style><br></div><div class="gmail_default" style>But it works pretty much the way I think we want here. We *always* want a TargetTransformInfo, and we have reasonable (conservative) stubs in place. We would just like the option of providing one from the target that has very clever implementations.</div>
<div class="gmail_default" style><br></div><div class="gmail_default" style>I would propose that we make TargetTransformInfo be an analysis group, and provide NoTargetTransformInfo as the shim implementation, and each target provide the more detailed one. This will allow consumers to use normal getAnalysis methods, etc.</div>
<div class="gmail_default" style><br></div><div class="gmail_default" style>As part of this, I'm planning to move all of TargetTransformInfo to lib/Analysis.</div><div class="gmail_default" style><br></div><div class="gmail_default" style>
I'd like to do this soon, so speak up if this sounds like a bad idea. =]</div><div class="gmail_default" style>-Chandler</div></div>