<div dir="ltr">I don't think there's any technical reason for the current structure. Your change sounds like an improvement to me. I'm curious if you have any compile time measurements from this change.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 4:59 AM Luke Drummond via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello<br>
<br>
I've been looking at the tables generated by<br>
`SequenceToOffsetTable::emit`, and notice that when the generated data<br>
are strings, the data is basically un-grep-able, and very tricky to<br>
read, as they are emitted as an array of comma-separated char-literal:<br>
<br>
extern const char HexagonInstrNameData[] = {<br>
/* 0 */ 'G', '_', 'F', 'L', 'O', 'G', '1', '0', 0,<br>
/* 9 */ 'E', 'N', 'D', 'L', 'O', 'O', 'P', '0', 0,<br>
/* 18 */ 'V', '6', '_', 'v', 'd', 'd', '0', 0,<br>
/* 26 */ 'P', 'S', '_', 'v', 'd', 'd', '0', 0,<br>
/* 34 */ 'V', '6', '_', 'l', 'd', '0', 0,<br>
/* 41 */ 'V', '6', '_', 'z', 'l', 'd', '0', 0,<br>
[...]<br>
};<br>
<br>
As far as I can see, this makes it more difficult than necessary to read<br>
for at least the following cases:<br>
<br>
Target AsmStrs<br>
Target InstrNameData<br>
Target RegStrings<br>
Target RegClassStrings<br>
<br>
<br>
I hacked together a fix for the above cases locally, and found that for<br>
at least for clang and gcc, the compile-time for generated tables is<br>
significantly reduced when emitting string literals, and the user can<br>
grep the name tables without huge effort. The above table is now:<br>
<br>
extern const char HexagonInstrNameData[] = {<br>
/* 0 */ "G_FLOG10\0"<br>
/* 9 */ "ENDLOOP0\0"<br>
/* 18 */ "V6_vdd0\0"<br>
/* 26 */ "PS_vdd0\0"<br>
/* 34 */ "V6_ld0\0"<br>
/* 41 */ "V6_zld0\0"<br>
[...]<br>
};<br>
<br>
My question then is: Is there a specific technical reason that we should<br>
avoid emitting concatenated string literals rather array of<br>
comma-separated char literals for "string-like" data?<br>
<br>
If not, I can probably post a patch, which I feel will make it much<br>
easier to understand the output from tablegen, and helps compilation<br>
speed of generated tables.<br>
<br>
Any thoughts appreciated.<br>
<br>
All the Best<br>
<br>
Luke<br>
<br>
-- <br>
Codeplay Software Ltd.<br>
Company registered in England and Wales, number: 04567874<br>
Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>