search for: featurefp16

Thanks Bradley. I see that the features set in /ARM.td/ get written to the generated file /<build>/llvm/lib/Target/ARM/ARMGenSubtargetInfo.inc./ Here the ProcA9 features appear in /ARMFeatureKV/ table: /{ "a9", "Cortex-A9 ARM processors", { ARM::ProcA9 }, { *ARM::FeatureFP16* } }, /With your change, the features for ProcA9 in the above entry are empty.//This ARMFeatureKV table is then read in MC/MCSubtargetInfo.cpp in the getFeatures() function. Thanks, Mandeep On 2/24/2016 2:42 AM, Bradley Smith wrote: > > Hi, > > The idea behind that change was to ma...

...and added to ProcessorModel definition (e.g.: ProcessorModel<"cortex-a9"). But I find that the features from Proc are still being read and set in MCSubtargetInfo through the ARMFeatureKV table. So if the Proc is empty the corresponding feature is not being set. In my case, if I add FeatureFP16 back to the ProcA9 definition in ARM.td I get back all the lost performance. Could you please give me some insight on how, after your change, do the Proc features get correctly set in MCSubtargetInfo and other places which access Proc? Thanks, Mandeep -------------- next part -------------- An...

On 15 September 2015 at 19:34, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > We can go further with this analogy too. For example, let's say John Smith > with the SSN Y also answers to the name Rameses. This is the problem that > Renato is working on. Renato needs to be able to see the name Rameses and > map this to the correct John Smith (or at least someone very