David Blaikie
2015-Apr-14 19:44 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
Adding llvm-dev as that might be a more suitable audience for this discussion. (& I know Lang's been playing around with the same problem in the Orc JIT, so adding him too) Is there any basis/reason to believe that the .X suffix is a better, more principled one than straight X? Is that documented somewhere as a thing the demangling tools will ignore? On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil < sunil_srivastava at playstation.sony.com> wrote:> Hi, > > > > We are running into a problem created by renaming of static symbols by > llvm-link. It first > > showed up using LTO, but we can illustrate this by using llvm-link as well. > > > > Say we have two files with the same named static symbol Bye > > > > --------------- t1.cpp --------- > > static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; } > > void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); } > > --------------- t2.cpp --------- > > static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; } > > void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); } > > > > --------- cmd sequence ------- > > $ clang++ -c -emit-llvm t1.cpp -o t1.bc > > $ clang++ -c -emit-llvm t1.cpp -o t2.bc > > $ llvm-link t1.bc t2.bc -o t23.bc > > $ clang -c t23.bc > > $ nm t23.o > > > > t1.o and t2.o have the same named function “_ZL3ByePi”. In order to > distinguish them, > > one gets a ‘1’ appended to it, making it “_ZL3ByePi1”. > > > > While the code is all correct, the problem is that this modified name > cannot be demangled. > > > > That is what I am trying to fix. > > > > In similar situations gcc appends a ‘.’ before appending the > discriminating number, making “_ZL3ByePi.1” > > > > The following change in lib/IR/ValueSymbolTable.cpp seems to fix this > problem. > > > > ------------ start diff ------------------- > > @@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) { > > // Trim any suffix off and append the next number. > > UniqueName.resize(BaseSize); > > - raw_svector_ostream(UniqueName) << ++LastUnique; > > + raw_svector_ostream(UniqueName) << "." << ++LastUnique; > > > > // Try insert the vmap entry with this suffix. > > -------------- end diff --------------------- > > > > However it causes 60 test failures. These are tests where some names that > are expecting > > to get a plain numeric suffix now have a ‘.’ before it. These are all > local symbols, so I think > > the generated code will always be correct, but the tests as written do not > pass. For > > example, take test/CodeGen/ARM/global-merge-addrspace.ll > > > > ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s > > ; Test the GlobalMerge pass. Check that the pass does not crash when using > > ; multiple address spaces. > > ; CHECK: _MergedGlobals: > > @g1 = internal addrspace(1) global i32 1 > > @g2 = internal addrspace(1) global i32 2 > > ; CHECK: _MergedGlobals1: > > @g3 = internal addrspace(2) global i32 3 > > @g4 = internal addrspace(2) global i32 4 > > > > With my change, the symbol is named MergedGlobals.1, hence it fails this > test. > > > > I could change these 60 tests to match the new behavior. That will fix > these 60 failures. > > However, I do have a concern that there may be other places in llvm that > expect the > > names to be pure identifiers. Adding a ‘.’ may cause them to fail. No such > failure has been > > seen in running the whole clang test, but the concern is still there. > > > > I should note that even local symbols are treated similarly, so for > example, a parameter > > named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’ currently > (an actual > > example from a test). > > > > Alternatively, I could try to limit my change to just mangled names. > > > > Any suggestion about how this should be fixed ? > > > > There is another similar change about 40 lines below in > ValueSymbolTable::createValueName(). > > That is not needed to fix this particular problem, but looks similar, so > perhaps should be treated > > similarly for consistency. It causes 66 more failures of the same nature > though. > > > > Thanks > > > > Sunil Srivastava > > Sony Computer Entertainment > > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150414/8e251a8c/attachment.html>
Richard Smith
2015-Apr-14 20:19 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
On Tue, Apr 14, 2015 at 12:44 PM, David Blaikie <dblaikie at gmail.com> wrote:> Adding llvm-dev as that might be a more suitable audience for this > discussion. > > (& I know Lang's been playing around with the same problem in the Orc JIT, > so adding him too) > > Is there any basis/reason to believe that the .X suffix is a better, more > principled one than straight X? Is that documented somewhere as a thing the > demangling tools will ignore? >At least for the Itanium ABI, it's possible for both ${foo} and ${foo}1 to be valid mangled names, so a demangler isn't able to ignore our current suffixes even in theory. Not an argument for .X, but it's an argument against plain X. On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil <> sunil_srivastava at playstation.sony.com> wrote: > >> Hi, >> >> >> >> We are running into a problem created by renaming of static symbols by >> llvm-link. It first >> >> showed up using LTO, but we can illustrate this by using llvm-link as >> well. >> >> >> >> Say we have two files with the same named static symbol Bye >> >> >> >> --------------- t1.cpp --------- >> >> static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; } >> >> void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); } >> >> --------------- t2.cpp --------- >> >> static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; } >> >> void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); } >> >> >> >> --------- cmd sequence ------- >> >> $ clang++ -c -emit-llvm t1.cpp -o t1.bc >> >> $ clang++ -c -emit-llvm t1.cpp -o t2.bc >> >> $ llvm-link t1.bc t2.bc -o t23.bc >> >> $ clang -c t23.bc >> >> $ nm t23.o >> >> >> >> t1.o and t2.o have the same named function “_ZL3ByePi”. In order to >> distinguish them, >> >> one gets a ‘1’ appended to it, making it “_ZL3ByePi1”. >> >> >> >> While the code is all correct, the problem is that this modified name >> cannot be demangled. >> >> >> >> That is what I am trying to fix. >> >> >> >> In similar situations gcc appends a ‘.’ before appending the >> discriminating number, making “_ZL3ByePi.1” >> >> >> >> The following change in lib/IR/ValueSymbolTable.cpp seems to fix this >> problem. >> >> >> >> ------------ start diff ------------------- >> >> @@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) { >> >> // Trim any suffix off and append the next number. >> >> UniqueName.resize(BaseSize); >> >> - raw_svector_ostream(UniqueName) << ++LastUnique; >> >> + raw_svector_ostream(UniqueName) << "." << ++LastUnique; >> >> >> >> // Try insert the vmap entry with this suffix. >> >> -------------- end diff --------------------- >> >> >> >> However it causes 60 test failures. These are tests where some names that >> are expecting >> >> to get a plain numeric suffix now have a ‘.’ before it. These are all >> local symbols, so I think >> >> the generated code will always be correct, but the tests as written do >> not pass. For >> >> example, take test/CodeGen/ARM/global-merge-addrspace.ll >> >> >> >> ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s >> >> ; Test the GlobalMerge pass. Check that the pass does not crash when using >> >> ; multiple address spaces. >> >> ; CHECK: _MergedGlobals: >> >> @g1 = internal addrspace(1) global i32 1 >> >> @g2 = internal addrspace(1) global i32 2 >> >> ; CHECK: _MergedGlobals1: >> >> @g3 = internal addrspace(2) global i32 3 >> >> @g4 = internal addrspace(2) global i32 4 >> >> >> >> With my change, the symbol is named MergedGlobals.1, hence it fails this >> test. >> >> >> >> I could change these 60 tests to match the new behavior. That will fix >> these 60 failures. >> >> However, I do have a concern that there may be other places in llvm that >> expect the >> >> names to be pure identifiers. Adding a ‘.’ may cause them to fail. No >> such failure has been >> >> seen in running the whole clang test, but the concern is still there. >> >> >> >> I should note that even local symbols are treated similarly, so for >> example, a parameter >> >> named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’ currently >> (an actual >> >> example from a test). >> >> >> >> Alternatively, I could try to limit my change to just mangled names. >> >> >> >> Any suggestion about how this should be fixed ? >> >> >> >> There is another similar change about 40 lines below in >> ValueSymbolTable::createValueName(). >> >> That is not needed to fix this particular problem, but looks similar, so >> perhaps should be treated >> >> similarly for consistency. It causes 66 more failures of the same nature >> though. >> >> >> >> Thanks >> >> >> >> Sunil Srivastava >> >> Sony Computer Entertainment >> >> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150414/69421957/attachment.html>
Srivastava, Sunil
2015-Apr-14 20:51 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
Hi David,
Thanks for adding Lang and other mailing lists.
Ø Is there any basis/reason to believe that the .X suffix is a better, more
principled one
Ø than straight X? Is that documented somewhere as a thing the demangling tools
Ø will ignore?
I don’t know of any documentation but the existing demangling tools, such as
c++filt on linux, already stop at ‘.’. So there is precedence.
Gcc bugzillas refer to this point. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831#c10 for an example.
Moreover, the issue exists in C as well, where the debugger will have no way of
distinguishing Bye from Bye1. They may still need some work for figuring out
Bye.1, but at least that is doable.
Sunil
From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Tuesday, April 14, 2015 12:44 PM
To: Srivastava, Sunil
Cc: cfe-dev at cs.uiuc.edu; LLVM Developers Mailing List; Lang Hames
Subject: Re: [cfe-dev] A problem with names that can not be demangled.
Adding llvm-dev as that might be a more suitable audience for this discussion.
(& I know Lang's been playing around with the same problem in the Orc
JIT, so adding him too)
Is there any basis/reason to believe that the .X suffix is a better, more
principled one than straight X? Is that documented somewhere as a thing the
demangling tools will ignore?
On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil <sunil_srivastava at
playstation.sony.com<mailto:sunil_srivastava at playstation.sony.com>>
wrote:
Hi,
We are running into a problem created by renaming of static symbols by
llvm-link. It first
showed up using LTO, but we can illustrate this by using llvm-link as well.
Say we have two files with the same named static symbol Bye
--------------- t1.cpp ---------
static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; }
void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); }
--------------- t2.cpp ---------
static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; }
void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); }
--------- cmd sequence -------
$ clang++ -c -emit-llvm t1.cpp -o t1.bc
$ clang++ -c -emit-llvm t1.cpp -o t2.bc
$ llvm-link t1.bc t2.bc -o t23.bc
$ clang -c t23.bc
$ nm t23.o
t1.o and t2.o have the same named function “_ZL3ByePi”. In order to distinguish
them,
one gets a ‘1’ appended to it, making it “_ZL3ByePi1”.
While the code is all correct, the problem is that this modified name cannot be
demangled.
That is what I am trying to fix.
In similar situations gcc appends a ‘.’ before appending the discriminating
number, making “_ZL3ByePi.1”
The following change in lib/IR/ValueSymbolTable.cpp seems to fix this problem.
------------ start diff -------------------
@@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) {
// Trim any suffix off and append the next number.
UniqueName.resize(BaseSize);
- raw_svector_ostream(UniqueName) << ++LastUnique;
+ raw_svector_ostream(UniqueName) << "." <<
++LastUnique;
// Try insert the vmap entry with this suffix.
-------------- end diff ---------------------
However it causes 60 test failures. These are tests where some names that are
expecting
to get a plain numeric suffix now have a ‘.’ before it. These are all local
symbols, so I think
the generated code will always be correct, but the tests as written do not pass.
For
example, take test/CodeGen/ARM/global-merge-addrspace.ll
; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s
; Test the GlobalMerge pass. Check that the pass does not crash when using
; multiple address spaces.
; CHECK: _MergedGlobals:
@g1 = internal addrspace(1) global i32 1
@g2 = internal addrspace(1) global i32 2
; CHECK: _MergedGlobals1:
@g3 = internal addrspace(2) global i32 3
@g4 = internal addrspace(2) global i32 4
With my change, the symbol is named MergedGlobals.1, hence it fails this test.
I could change these 60 tests to match the new behavior. That will fix these 60
failures.
However, I do have a concern that there may be other places in llvm that expect
the
names to be pure identifiers. Adding a ‘.’ may cause them to fail. No such
failure has been
seen in running the whole clang test, but the concern is still there.
I should note that even local symbols are treated similarly, so for example, a
parameter
named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’ currently (an
actual
example from a test).
Alternatively, I could try to limit my change to just mangled names.
Any suggestion about how this should be fixed ?
There is another similar change about 40 lines below in
ValueSymbolTable::createValueName().
That is not needed to fix this particular problem, but looks similar, so perhaps
should be treated
similarly for consistency. It causes 66 more failures of the same nature though.
Thanks
Sunil Srivastava
Sony Computer Entertainment
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150414/808e5df0/attachment.html>
Cary Coutant
2015-Apr-16 20:46 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
GCC has a generalized mangling syntax for cloned functions. See GCC PR 40831: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 and the discussion thread here: https://gcc.gnu.org/ml/gcc-patches/2011-09/msg01375.html -cary On Tue, Apr 14, 2015 at 12:44 PM, David Blaikie <dblaikie at gmail.com> wrote:> Adding llvm-dev as that might be a more suitable audience for this > discussion. > > (& I know Lang's been playing around with the same problem in the Orc JIT, > so adding him too) > > Is there any basis/reason to believe that the .X suffix is a better, more > principled one than straight X? Is that documented somewhere as a thing the > demangling tools will ignore? > > On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil > <sunil_srivastava at playstation.sony.com> wrote: >> >> Hi, >> >> >> >> We are running into a problem created by renaming of static symbols by >> llvm-link. It first >> >> showed up using LTO, but we can illustrate this by using llvm-link as >> well. >> >> >> >> Say we have two files with the same named static symbol Bye >> >> >> >> --------------- t1.cpp --------- >> >> static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; } >> >> void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); } >> >> --------------- t2.cpp --------- >> >> static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; } >> >> void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); } >> >> >> >> --------- cmd sequence ------- >> >> $ clang++ -c -emit-llvm t1.cpp -o t1.bc >> >> $ clang++ -c -emit-llvm t1.cpp -o t2.bc >> >> $ llvm-link t1.bc t2.bc -o t23.bc >> >> $ clang -c t23.bc >> >> $ nm t23.o >> >> >> >> t1.o and t2.o have the same named function “_ZL3ByePi”. In order to >> distinguish them, >> >> one gets a ‘1’ appended to it, making it “_ZL3ByePi1”. >> >> >> >> While the code is all correct, the problem is that this modified name >> cannot be demangled. >> >> >> >> That is what I am trying to fix. >> >> >> >> In similar situations gcc appends a ‘.’ before appending the >> discriminating number, making “_ZL3ByePi.1” >> >> >> >> The following change in lib/IR/ValueSymbolTable.cpp seems to fix this >> problem. >> >> >> >> ------------ start diff ------------------- >> >> @@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) { >> >> // Trim any suffix off and append the next number. >> >> UniqueName.resize(BaseSize); >> >> - raw_svector_ostream(UniqueName) << ++LastUnique; >> >> + raw_svector_ostream(UniqueName) << "." << ++LastUnique; >> >> >> >> // Try insert the vmap entry with this suffix. >> >> -------------- end diff --------------------- >> >> >> >> However it causes 60 test failures. These are tests where some names that >> are expecting >> >> to get a plain numeric suffix now have a ‘.’ before it. These are all >> local symbols, so I think >> >> the generated code will always be correct, but the tests as written do not >> pass. For >> >> example, take test/CodeGen/ARM/global-merge-addrspace.ll >> >> >> >> ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s >> >> ; Test the GlobalMerge pass. Check that the pass does not crash when using >> >> ; multiple address spaces. >> >> ; CHECK: _MergedGlobals: >> >> @g1 = internal addrspace(1) global i32 1 >> >> @g2 = internal addrspace(1) global i32 2 >> >> ; CHECK: _MergedGlobals1: >> >> @g3 = internal addrspace(2) global i32 3 >> >> @g4 = internal addrspace(2) global i32 4 >> >> >> >> With my change, the symbol is named MergedGlobals.1, hence it fails this >> test. >> >> >> >> I could change these 60 tests to match the new behavior. That will fix >> these 60 failures. >> >> However, I do have a concern that there may be other places in llvm that >> expect the >> >> names to be pure identifiers. Adding a ‘.’ may cause them to fail. No such >> failure has been >> >> seen in running the whole clang test, but the concern is still there. >> >> >> >> I should note that even local symbols are treated similarly, so for >> example, a parameter >> >> named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’ currently >> (an actual >> >> example from a test). >> >> >> >> Alternatively, I could try to limit my change to just mangled names. >> >> >> >> Any suggestion about how this should be fixed ? >> >> >> >> There is another similar change about 40 lines below in >> ValueSymbolTable::createValueName(). >> >> That is not needed to fix this particular problem, but looks similar, so >> perhaps should be treated >> >> similarly for consistency. It causes 66 more failures of the same nature >> though. >> >> >> >> Thanks >> >> >> >> Sunil Srivastava >> >> Sony Computer Entertainment >> >> >> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Jonathan Roelofs
2015-Apr-16 21:01 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
On 4/14/15 2:51 PM, Srivastava, Sunil wrote:> > I don’t know of any documentation but the existing demangling tools,https://mentorembedded.github.io/cxx-abi/abi.html#mangling -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Rafael Espíndola
2015-Apr-17 18:42 UTC
[LLVMdev] [cfe-dev] A problem with names that can not be demangled.
So looks like just adding a "." wold work. My preference would be to
do it for all Values and update the tests.
Also, the code currently looks like
-------------------------
unsigned BaseSize = UniqueName.size();
while (1) {
// Trim any suffix off and append the next number.
UniqueName.resize(BaseSize);
raw_svector_ostream(UniqueName) << ++LastUnique;
-------------------------
Which means that currently if a name passes here multiple times we get
foo -> foo1 -> foo12
With the '.' we could change BaseSize to get
foo -> foo.1 -> foo.2
Cheers,
Rafael
On 16 April 2015 at 16:46, Cary Coutant <ccoutant at gmail.com>
wrote:> GCC has a generalized mangling syntax for cloned functions. See GCC PR
40831:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
>
> and the discussion thread here:
>
> https://gcc.gnu.org/ml/gcc-patches/2011-09/msg01375.html
>
> -cary
>
>
>
> On Tue, Apr 14, 2015 at 12:44 PM, David Blaikie <dblaikie at
gmail.com> wrote:
>> Adding llvm-dev as that might be a more suitable audience for this
>> discussion.
>>
>> (& I know Lang's been playing around with the same problem in
the Orc JIT,
>> so adding him too)
>>
>> Is there any basis/reason to believe that the .X suffix is a better,
more
>> principled one than straight X? Is that documented somewhere as a thing
the
>> demangling tools will ignore?
>>
>> On Tue, Apr 14, 2015 at 12:06 PM, Srivastava, Sunil
>> <sunil_srivastava at playstation.sony.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> We are running into a problem created by renaming of static symbols
by
>>> llvm-link. It first
>>>
>>> showed up using LTO, but we can illustrate this by using llvm-link
as
>>> well.
>>>
>>>
>>>
>>> Say we have two files with the same named static symbol Bye
>>>
>>>
>>>
>>> --------------- t1.cpp ---------
>>>
>>> static void Bye(int* ba1) { ba1[0] /= ba1[2] - 2; }
>>>
>>> void main_a( int* inB) { void (*func)(int*) = Bye; func(inB); }
>>>
>>> --------------- t2.cpp ---------
>>>
>>> static void Bye(int* ba1) { ba1[0] *= ba1[2] + 2; }
>>>
>>> void main_b( int* inB) { void (*func)(int*) = Bye; func(inB+1); }
>>>
>>>
>>>
>>> --------- cmd sequence -------
>>>
>>> $ clang++ -c -emit-llvm t1.cpp -o t1.bc
>>>
>>> $ clang++ -c -emit-llvm t1.cpp -o t2.bc
>>>
>>> $ llvm-link t1.bc t2.bc -o t23.bc
>>>
>>> $ clang -c t23.bc
>>>
>>> $ nm t23.o
>>>
>>>
>>>
>>> t1.o and t2.o have the same named function “_ZL3ByePi”. In order to
>>> distinguish them,
>>>
>>> one gets a ‘1’ appended to it, making it “_ZL3ByePi1”.
>>>
>>>
>>>
>>> While the code is all correct, the problem is that this modified
name
>>> cannot be demangled.
>>>
>>>
>>>
>>> That is what I am trying to fix.
>>>
>>>
>>>
>>> In similar situations gcc appends a ‘.’ before appending the
>>> discriminating number, making “_ZL3ByePi.1”
>>>
>>>
>>>
>>> The following change in lib/IR/ValueSymbolTable.cpp seems to fix
this
>>> problem.
>>>
>>>
>>>
>>> ------------ start diff -------------------
>>>
>>> @@ -54,5 +54,5 @@ void ValueSymbolTable::reinsertValue(Value* V) {
>>>
>>> // Trim any suffix off and append the next number.
>>>
>>> UniqueName.resize(BaseSize);
>>>
>>> - raw_svector_ostream(UniqueName) << ++LastUnique;
>>>
>>> + raw_svector_ostream(UniqueName) << "."
<< ++LastUnique;
>>>
>>>
>>>
>>> // Try insert the vmap entry with this suffix.
>>>
>>> -------------- end diff ---------------------
>>>
>>>
>>>
>>> However it causes 60 test failures. These are tests where some
names that
>>> are expecting
>>>
>>> to get a plain numeric suffix now have a ‘.’ before it. These are
all
>>> local symbols, so I think
>>>
>>> the generated code will always be correct, but the tests as written
do not
>>> pass. For
>>>
>>> example, take test/CodeGen/ARM/global-merge-addrspace.ll
>>>
>>>
>>>
>>> ; RUN: llc < %s -mtriple=thumb-apple-darwin -O3 | FileCheck %s
>>>
>>> ; Test the GlobalMerge pass. Check that the pass does not crash
when using
>>>
>>> ; multiple address spaces.
>>>
>>> ; CHECK: _MergedGlobals:
>>>
>>> @g1 = internal addrspace(1) global i32 1
>>>
>>> @g2 = internal addrspace(1) global i32 2
>>>
>>> ; CHECK: _MergedGlobals1:
>>>
>>> @g3 = internal addrspace(2) global i32 3
>>>
>>> @g4 = internal addrspace(2) global i32 4
>>>
>>>
>>>
>>> With my change, the symbol is named MergedGlobals.1, hence it fails
this
>>> test.
>>>
>>>
>>>
>>> I could change these 60 tests to match the new behavior. That will
fix
>>> these 60 failures.
>>>
>>> However, I do have a concern that there may be other places in llvm
that
>>> expect the
>>>
>>> names to be pure identifiers. Adding a ‘.’ may cause them to fail.
No such
>>> failure has been
>>>
>>> seen in running the whole clang test, but the concern is still
there.
>>>
>>>
>>>
>>> I should note that even local symbols are treated similarly, so for
>>> example, a parameter
>>>
>>> named ‘str’ becomes ‘str.1’ with my change, instead of ‘str1’
currently
>>> (an actual
>>>
>>> example from a test).
>>>
>>>
>>>
>>> Alternatively, I could try to limit my change to just mangled
names.
>>>
>>>
>>>
>>> Any suggestion about how this should be fixed ?
>>>
>>>
>>>
>>> There is another similar change about 40 lines below in
>>> ValueSymbolTable::createValueName().
>>>
>>> That is not needed to fix this particular problem, but looks
similar, so
>>> perhaps should be treated
>>>
>>> similarly for consistency. It causes 66 more failures of the same
nature
>>> though.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Sunil Srivastava
>>>
>>> Sony Computer Entertainment
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev