[PATCH] D24661: More processors support under AARch64 state for auto detection.

[Tim Northover via llvm-commits]

> Or do you mean the "for" loop body itself is inefficient (and not the for
> loop being repeated) in the sense that there is lot of strcmp?

It's more the code duplication aspect that bothers me.

> 1. Converting to numbers to be used in lower_bound on a static array needs
> maintenance (manual sorting). It might be prone to errors especially when
> the "CPU Part" strings (like 0xd03, etc.) change the sequence in future. One
> has to be very careful then.

In similar situations in Clang I've used
"assert(std::is_sorted(...))". Elides to nothing in release builds but
stops people getting it wrong when modifying the table manually. Using
TableGen in some manner to generate the search is another option,
though I'd probably say not worth it here.

> 2. Definitely reduces readability. The current approach is very neat.

I disagree. Looking through dozens of lines that may or may not be
identical after whatever patches have introduced Samsung, Qualcomm,
Apple, and whatever parsing is really something I want to avoid.

> 4. The list may not really grow up to many such entries under one single
> implementer. In my opinion we can live with the penalty given other
> benefits.

I'm still not seeing the benefits, I'm afraid.

> In fact this whole thing of parsing /proc/cpuinfo itself is inefficient, but
> cant help in case of ARM. Even querying their Main ID Register (MIDR) or
> HWCAP is not complete. I just wish we had an system call interface (through
> libc) to query different aspects of procfs (/proc) - Some sort of a
> software-cpuid.

Now that I could get behind!

Tim.