[PATCH] MC: Use StringRef to avoid strcmp/strlen on non-null-term'd strings.

[Will Dietz]

On Sun, Oct 13, 2013 at 12:46 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>>> Are either concerns something to be sufficiently concerned about that
>>> they should be measured, and if so any recommenedations on how I might
>>> do so?
>>
>> I would prefer not doing this.
>>
>> * StringRef in a compile-time initialized array adds static initializers because the struct is no longer POD.
>
> I don't think this code is used in static initializers. I got the same
> size for .init and .init_array when building clang with and without
> this patch in debug mode.
>

Diving into this further, a dump of the resulting llc binaries shows
without my patch
the X86ProcSchedKV (for example) table is present, but with my patch the section
is all zeros.

I'm also seeing identical .init/.init_array sizes, but further poking shows
that symbols like
_GLOBAL__sub_I_ARMMCTargetDesc.cpp
are significantly larger.  Presumably this is where the initialization is done,
and setting a breakpoint on it confirms its called before main().

Darn, I was hopeful the compiler was able to see through the StringRef
constructor and statically evaluate the calls to strlen() etc :).
Would be pretty nifty, although wouldn't solve issue of the tables being larger.

Anyway, attached is an updated patch that avoids these issues
(as well as the dodgy format() code) by using a new comparator
for doing the lower_bound with a StringRef, as suggested.

Look good?

Thanks!

~Will

PS: Anyone know of a good reference for understanding how
all this initialization is typically done?  I've typically pulled up
a debugger and libc source code, but am interested in
more of a design document, if such exists.  Thanks!

> Cheers,
> Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-MC-Don-t-assume-incoming-StringRef-s-are-null-termin.patch
Type: application/octet-stream
Size: 3310 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131013/f8221186/attachment.obj>