On Tue, 2019-01-22 at 18:51 +0000, Honnappa Nagarahalli wrote: > External Email > > Removed tspe...@qti.qualcomm.com as the email address is not > reachable. > > > > > > I'll come up with a new patch based on the discussion here. > > > > > A few things noted, > > > > > - we still want it to be 128B for generic build > > > > > - we at least agreed on changing it to 64B for A72 > > > > How will this be done? Will you add > > > > config/arm/arm64_bluefield_linuxapp_gcc? > > > I asked this question as there was a proposal containing 'a72' in > > > the > > > file name. IMO, the file name should contain 'bluefield', not on > > > a72. > > > > Sorry for late reply. It's been buried for some reason. :-) > No problem > > > Nope, I won't create such a file. That's for cross-compiler AFAIK. > > I'm thinking about changing meson.build. Currently, one CL size is > > applied to > > all kinds of cores. Consequently, for armv8a, both 'default' and > > 'a72' have to > > have the same CL size. And one more thing raised from ARM was that > > 'crypto' in -march can't be a default. > Yes, crypto is optional. So, the distro builds (and any other builds > for binary compatibility) should not expect crypto to be present by > default.
IMO, crypto case is different where DPDK code check at runtime to see crypto instruction present in the given CPU before it uses any crypto instructions. so IMO, There is no harm in building with crypto enabled unlike other gcc flags.
