gollvm: capture-fcn-attributes.go generates the header file with improperly chosen CPU model (i686; yonah)

[advancedwebdeveloper]

This issue is related to https://go-review.googlesource.com/c/gollvm/+/274574
.

I think I have some misunderstanding on how you used to deal with CPU models, for LLVM.

First things first - I had success with using

#include "llvm/ADT/StringRef.h"
#include "llvm/ADT/StringMap.h"
#include "llvm/MC/SubtargetFeature.h"
#include "llvm/Support/Host.h"

using namespace llvm;
SubtargetFeatures Features1;

int main (int argc, char **argv)
{
sys::getHostCPUName();
StringMap HostFeatures;
if (sys::getHostCPUFeatures(HostFeatures))
for (auto &F : HostFeatures)
Features1.AddFeature(F.first(), F.second);

printf("test %s", Features1.getString().c_str());
printf("\nsomething else\n");
return 0;
}
. It gives me such a set of CPU features:

+sse2,-tsxldtrk,-cx16,-sahf,-tbm,-avx512ifma,-sha,-gfni,-fma4,-vpclmulqdq,-prfchw,-bmi2,-cldemote,-fsgsbase,-ptwrite,-amx-tile,-avx512bf16,-popcnt,-aes,-avx512bitalg,-movdiri,-xsaves,-avx512er,-xsavec,-avx512vnni,-amx-bf16,-avx512vpopcntdq,-pconfig,-clwb,-avx512f,-clzero,-pku,+mmx,-lwp,-rdpid,-xop,-rdseed,-waitpkg,-movdir64b,-sse4a,-avx512bw,-clflushopt,-xsave,-avx512vbmi2,-64bit,-avx512vl,-serialize,-invpcid,-avx512cd,-avx,-vaes,+cx8,-fma,-rtm,-bmi,-enqcmd,-rdrnd,-mwaitx,-sse4.1,-sse4.2,-avx2,+fxsr,-wbnoinvd,+sse,-lzcnt,-pclmul,-prefetchwt1,-f16c,-ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-amx-int8,-movbe,-avx512vp2intersect,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3

$ llc --version
provides
Default target: i686-pc-linux-gnu
Host CPU: yonah
.

I tried to update the capture-fcn-attributes.go file, like this:

var supportedTriples []string = []string{
"x86_64-unknown-linux-gnu",
"i686-pc-linux-gnu",
"aarch64-unknown-linux-gnu",
}
.

When I tried the generator

capture-fcn-attributes -o /tmp/cpu_feature_list
it generated me a broad list.
The header contained

Ubuntu clang version 11.0.0-++20200721055954+cebd637c886-1exp120200721161335.13
.
I found

// triple: i686-pc-linux-gnu
static const CpuAttrs attrs1[] = {
// first entry is default cpu
{ "i686", "+cx8,+x87"},

and (inside the hashmap)

{ "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
, which is not what I have supported (for Intel Celeron M440).
Clang reports "unsupported CPU features" on any non-provided one.
So that is one big problem.
Next problem is that

const TripleCpus triples[] = {
{ "x86_64-unknown-linux-gnu", &attrs0[0] },
{ "i686-pc-linux-gnu", &attrs1[0] },
{ "aarch64-unknown-linux-gnu", &attrs2[0] },
{ "", nullptr } // sentinel
};
is not targeting to yonah, while llc is targeting it.
It is always some "default" CPU model and, in fact, your code never provided extraction of the CPU model (from llc).

To make my observation complete - I am providing what is generated via

capture-fcn-attributes -cpu yonah
:

// triple: x86_64-unknown-linux-gnu
static const CpuAttrs attrs0[] = {
// first entry is default cpu
{ "x86-64", "+cx8,+fxsr,+mmx,+sse,+sse2,+x87"},
{ "", "" } // sentinel
};

// triple: i686-pc-linux-gnu
static const CpuAttrs attrs1[] = {
// first entry is default cpu
{ "i686", "+cx8,+x87"},
{ "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
{ "", "" } // sentinel
};

// triple: aarch64-unknown-linux-gnu
static const CpuAttrs attrs2[] = {
// first entry is default cpu
{ "generic", "+neon"},
{ "", "" } // sentinel
};

const TripleCpus triples[] = {
{ "x86_64-unknown-linux-gnu", &attrs0[0] },
{ "i686-pc-linux-gnu", &attrs1[0] },
{ "aarch64-unknown-linux-gnu", &attrs2[0] },
{ "", nullptr } // sentinel
};
.

I tried

capture-fcn-attributes -cpu yonah -triples i686-pc-linux-gnu
and got

// triple: i686-pc-linux-gnu
static const CpuAttrs attrs0[] = {
// first entry is default cpu
{ "i686", "+cx8,+x87"},
{ "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"},
{ "", "" } // sentinel
};

const TripleCpus triples[] = {
{ "i686-pc-linux-gnu", &attrs0[0] },
{ "", nullptr } // sentinel
};
.

I understand that your strategy worked find on Intel based system-on-board machines - but didn't try something for AMD (yet).
Nevertheless I have these issues on i686 - so I am proposing to perform a review.

[thanm]

This is not a bug -- it's a discussion of ongoing gollvm work. Please move it to a mailing list; happy to respond there.

[advancedwebdeveloper]

https://groups.google.com/g/golang-nuts/c/osy40rhf_Yk - done