<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 21, 2016 at 3:18 PM Matthias Braun <<a href="mailto:mbraun@apple.com">mbraun@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 20, 2016, at 1:50 PM, Eric Christopher via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br>+def ProcVulcan  : SubtargetFeature<"vulcan", "ARMProcFamily", "Vulcan",<br>+                                   "Broadcom Vulcan processors", [<br>+                                   FeatureFPARMv8,<br>+                                   FeatureNEON,<br>+                                   FeatureCrypto,<br>+                                   FeatureCRC,<br>+                                   HasV8_1aOps]>;<br>+<br></blockquote><div><br></div><div>So, why are all of the processors given as SubtargetFeatures as well as processors? This seems ... less than optimal. I.e. I can't come up with a reason I'd want to say "llc -mattr=+vulcan" rather than llc -mcpu=vulcan.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Yes the pattern is strange. But there is one problem today: We want to initialize a bunch of cost values. This is currently done in  Arch64::Subtarget::initializeProperties(). These costs are really per CPU so we need to set the ProcFamily enum per CPU. Initializing the cost values together with the processor definition in tablegen would have been nicer but is not sanely possible today.</div></div><div>(Using the SubtargetFeatures doesn't cut it, because I need 1 feature for each variable+value combination, the generated code always goes for the minimum in case the var is initialized multiple times while I sometimes want max, I shouldn't have boolean -mattrs for initializing cost values, etc.)</div></div><div style="word-wrap:break-word"><br></div></blockquote><div><br></div><div>Agreed, setting a table of TTI values might be nice. Some other targets just switch on features that exist, and I can't come up with another way to do this cheaply (there's always StringSwitch!) in every place that should be returning the values in TTI (as an example) without needing an explicit switch on strings. The cost values can definitely be stored in the subtarget, but you don't necessarily need a SubtargetFeature for a cpu as a way of setting things up - you can use the CPU value.</div><div><br></div><div>-eric</div></div></div>