craig.topper added inline comments.
================ Comment at: clang/lib/Basic/Targets/X86.cpp:1738 +// +------------------------------------+-------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ +// | i386 | 64 | https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf | +// | i486 | 64 | "four doublewords" https://en.wikichip.org/w/images/d/d3/i486_MICROPROCESSOR_HARDWARE_REFERENCE_MANUAL_%281990%29.pdf | ---------------- zoecarver wrote: > craig.topper wrote: > > I'd be surprised if 386 is larger than 486 or 586. > Yes, it does seem surprising but this other source corroborates it > https://osxbook.com/blog/2009/03/02/retrieving-x86-processor-information/ -march=i386 there seem just seems to be a compiler switch. The 386 CPU didn't have CPUID, that was added on the 486. The dump there seems to be a dump from Nehalem. They just compiled the code targeting a really old CPU for some reason. Thinking about it more, the 386 is a bit weird because the cache wasn't part of the CPU, it was on the motherboard and not always present. Not sure what that means for cache line size. I have an ancient 386 hardware manual in my cube at work, maybe I can find something in there. ================ Comment at: clang/lib/Basic/Targets/X86.cpp:1834 + case CK_Tigerlake: + case CK_Lakemont: + ---------------- zoecarver wrote: > craig.topper wrote: > > I think Lakemont is 16 bytes. Assuming I'm interpretting the CLFLUSH line > > size from this CPUID dump correctly > > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIntel/GenuineIntel0000590_Lakemont_CPUID2.txt > > > I may very well be interpreting this incorrectly but I think that the cache > line sizes are at `eax = 0x80000005` and `eax = 0x80000006`. However, all the > registers at those codes are zero. If I instead look at `eax = 0x00000001` > (which I think is incorrect), `ecx = 00010200` which would be 128 bytes > (maybe this is where the 16 came from, if they were bits instead?). How were > you interpreting it? Interpreted bits 15:8 of the ecx = 00010200 to be the clflush information. The spec for cpuid says to multiply by 8 to get cache line size. So 15:8 is 2, multiply by 8 is 16 bytes. I think Lakemont is based on the 486 architecture so that seems possible. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74918/new/ https://reviews.llvm.org/D74918 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
