Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
От: mehdi.am...@apple.com от имени Mehdi Amini
Отправлено: 27 сентября 2016 г. 8:46
Кому: Perevalov Alexey
Копия: cfe-users@lists.llvm.org; llvm-...@lists.llvm.org
Тема: Re: [llvm-dev] objc object file generated for gnustep runtime for ELF
target is too big
> On Sep 26, 2016, at 6:33 AM, Perevalov Alexey via llvm-dev
> wrote:
>
> Dear community,
>
>
> I'm using gnustep runtime -fobjc-runtime=gnustep with gnustep-libobjc2
> (https://github.com/gnustep/libobjc2) and
>
> Cocotron/Chameleon.
>
> For following source file
>
> #import
> #import
>
> int main(void)
> {
> NSString *str = [NSString stringWithCString:"TEST"];
> NSLog(@"test object %@", str);
> return 0;
> }
>
> Compilation in xcode's clang
>Which version?
I think, it doesn't matter, due to with xcode's clang all fine
but if you intersting,
xcrun -sdk iphoneos clang --version
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix
also all fine with open source llvm clang if I choose ios as -fobjc-runtime, I
got troubles only with gnustep runtime in clang+llvm-3.8.0 and 3.9.x.
>—
>Mehdi
> xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c
> test_foundation.m -o test_foundation_apple.o
> gives following result:
> 1. object file has only 3156 bytes size
> 2. and in disassembler only main function
> 3. the final executable will be 49992 bytes size in this case
>
>
> But compilation in llvm's clang downloaded from
> http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
>
> (
> clang version 3.8.0 (tags/RELEASE_380/final)
> Target: x86_64-apple-darwin15.0.0
> Thread model: posix
> )
> gives another results:
> 1. object file has 159044 bytes size
> 2. in disassembler a lot of unnecessary .objc_property_list,
> .objc_method_list, .objc_protocol_list and .objc_protocol in .bss and
> .data section
> 3. the final binary size is 101837 bytes size
>
>
>
> If comment in above sample #import file and binary file in xcode compilation will be the same,
> but size binary and object file in case of
> clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced
> sufficiently:
> binary 28569 and object 36952 accordingly.
>
>
>
> Looks like all protocols from UIKit.h is placed into binary/object even
> it's not used there.
> I got 3.9.0 from public git (branch release_39 of clang git repository)
> and found that all protocols interpret as definition
> (isThisDeclarationADefinition),
> and in CGObjCGNU.cpp it's placed into object file whenever it's used or
> not. With the same open source compiler and -fobjc-runtime=ios
> protocols are not putting into
> object file even in compilation for ELF (I used -target
> arm-linux-gnueabi).
> I used default binutil linker, not llvm's ld.ldd, due to I have problem with
> relocation on ARM.
> I didn't use LTO, due to my linker doesn't have plugin support (I didnt' yet
> recompile it).
>
> Could somebody point me where to solve that problem, is it AST
> generation stage, or linkage stage or maybe it's not a problem and just LTO
> could be solution here?
>
>
>
>
> p.s. It's not only one issue found by me in gnustep runtime generation,
> and I'll report these issues in next emails.
>
>
>
>
>
> Best regards,
> Alexey Perevalov
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
llvm-dev Info Page
lists.llvm.org
To see the collection of prior postings to the list, visit the llvm-dev
Archives. Using llvm-dev: To post a message to all the list members, send ...
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] libclang: Spelling on typedefs lacks namespaces
Nobody? Wrong list? Any insight in this would be greatly appreciated.
Thanks
Michael
On 08/30/2016 07:00 PM, Michael via cfe-users wrote:
Hi
Hope I picked the right place for this kind of problem, if not please
let me know.
I'm using libclang to parse header files and generate code from them.
I found that clang_getTypeSpelling() usually includes the namespace(s)
a type was declared in. However with the exception being typedefs (and
same for "using A = B"). Not sure if this is a bug or intended
behavior, but it seems at least inconsistent. I also couldn't really
find a good workaround for this. I'd have to manually figure out all
typedefs (not just pure typedefs, they could also be template
parameters or whatever) and then their originating namespaces. This
sounds a bit cumbersome and not really straight forward.
Minimal example:
namespace foo {
class Bar {
};
typedef Bar BarDef;
}
clang_getTypeSpelling on "Bar" (kind "Record") gives: "foo::Bar"
clang_getTypeSpelling on "BarDef" (kind "Typedef") gives: "BarDef"
(<== missing "foo::")
Any idea how to solve this problem? Am I missing something?
Thanks
Michael
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] libclang: Spelling on typedefs lacks namespaces
Hi Michael,
I haven't used libclang much (my use case requires LibTooling) but I think
you want to get the underlying type from the typedef and then use
getTypeSpelling on that result. Basically you want to check if CXType.kind
is CXType_Typedef and if so, get the underlying type (which in this case
should be "Bar") and then call clang_getTypeSpelling on that result.
I don't know anything about CXCursors or CXTypes so I'll leave it to you to
figure out how to get the underlying type, but hopefully this helps.
-Adam
On Tue, Sep 27, 2016 at 8:55 AM, Michael via cfe-users <
cfe-users@lists.llvm.org> wrote:
> Nobody? Wrong list? Any insight in this would be greatly appreciated.
>
> Thanks
>
> Michael
>
>
> On 08/30/2016 07:00 PM, Michael via cfe-users wrote:
>
>> Hi
>>
>> Hope I picked the right place for this kind of problem, if not please let
>> me know.
>>
>> I'm using libclang to parse header files and generate code from them. I
>> found that clang_getTypeSpelling() usually includes the namespace(s) a type
>> was declared in. However with the exception being typedefs (and same for
>> "using A = B"). Not sure if this is a bug or intended behavior, but it
>> seems at least inconsistent. I also couldn't really find a good workaround
>> for this. I'd have to manually figure out all typedefs (not just pure
>> typedefs, they could also be template parameters or whatever) and then
>> their originating namespaces. This sounds a bit cumbersome and not really
>> straight forward.
>>
>> Minimal example:
>>
>> namespace foo {
>> class Bar {
>> };
>> typedef Bar BarDef;
>> }
>>
>> clang_getTypeSpelling on "Bar" (kind "Record") gives: "foo::Bar"
>> clang_getTypeSpelling on "BarDef" (kind "Typedef") gives: "BarDef" (<==
>> missing "foo::")
>>
>> Any idea how to solve this problem? Am I missing something?
>>
>> Thanks
>>
>> Michael
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] What are the ll lines starting with '!0', '!1', etc? How to retrieve them?
In the IR text, I see lines like:
!0 = !{void (float*)* @_Z11somekernel1Pf, !"kernel", i32 1}
!1 = !{void (float*)* @_Z3fooPf, !"kernel", i32 1}
What are these? How to retrieve them, given eg a Module *. I've tried
iterating over the global variables, named metadata, and aliases, but
nothing. I'm trying:
for(auto it=M->named_metadata_begin(); it != M->named_metadata_end();
it++) {
NamedMDNode *namedMDNode = &*it;
cout << "namedmdnode " << namedMDNode << endl;
cout << "name " << string(namedMDNode->getName()) << endl;
}
for(auto it=M->global_begin(); it != M->global_end(); it++) {
GlobalVariable *global = &*it;
cout << "global " << global << endl;
cout << string(global->getName()) << endl;
}
for(auto it=M->alias_begin(); it != M->alias_end(); it++) {
GlobalAlias *alias = &*it;
cout << "alias " << alias << endl;
cout << string(alias->getName()) << endl;
}
Result:
namedmdnode 0x1655cf0
name nvvm.annotations
namedmdnode 0x1658a00
name llvm.ident
namedmdnode 0x1658c10
name nvvm.internalize.after.link
namedmdnode 0x1658cd0
name nvvmir.version
global 0x164f468
.str
global 0x1650ac8
llvm.used
It seems like what I want is 'annotations', because in the ll, the
nvvm.annotations looks like:
!nvvm.annotations = !{!0, !1, !2, !3, !2, !4, !4, !4, !4, !5, !5, !4}
... and that seems like it references these !0, !1 lines somehow?
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Fwd: clang/llvm 3.9 bug
Hi,
Please find attached a short c test program which does not behave correctly
with clang 3.9.
I'm running ubuntu 16.04 64bit
clang bug.c
./a.out for gcc 5.4.0 / clang3.8 output:
1 1 0 1
1 1 0 1
./a.out for clang3.9 output:
0 0 0 0
0 0 0 0
Is that a regression?
Regards,
Christophe
#include
#include
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef double __v2df __attribute__ ((__vector_size__ (16)));
void fun32(){
float f1 = 689.256;
uint32_t qnan = 0x7FC1;
float f2 = *(float*)&qnan;
int equal = __builtin_ia32_ucomieq((__v4sf) { f1, 0.0, 0.0, 0.0 }, (__v4sf) { f2, 0.0, 0.0, 0.0 });
int lesser = __builtin_ia32_ucomilt((__v4sf) { f1, 0.0, 0.0, 0.0 }, (__v4sf) { f2, 0.0, 0.0, 0.0 });
int greater = __builtin_ia32_ucomigt((__v4sf) { f1, 0.0, 0.0, 0.0 }, (__v4sf) { f2, 0.0, 0.0, 0.0 });
int unordered = equal & lesser & ~greater;
fprintf(stderr, "%d %d %d %d\n", equal, lesser, greater, unordered);
}
void fun64(){
uint64_t ui64_1 = 0x7F80ULL;
uint64_t ui64_2 = 0x7FF8ULL;
double f1 = *(double*)&ui64_1;
double f2 = *(double*)&ui64_2;
int equal = __builtin_ia32_ucomisdeq((__v2df) { f1, 0.0 }, (__v2df) { f2, 0.0 });
int lesser = __builtin_ia32_ucomisdlt((__v2df) { f1, 0.0 }, (__v2df) { f2, 0.0 });
int greater = __builtin_ia32_ucomisdgt((__v2df) { f1, 0.0 }, (__v2df) { f2, 0.0 });
int unordered = equal & lesser & ~greater;
fprintf(stderr, "%d %d %d %d\n", equal, lesser, greater, unordered);
}
int main(){
fun32();
fun64();
return 0;
}
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] What are the ll lines starting with '!0', '!1', etc? How to retrieve them?
(Oh i see, the NamedMDNode contains MDNodes )
On Tue, Sep 27, 2016 at 3:22 PM, Hugh Perkins wrote:
> In the IR text, I see lines like:
>
> !0 = !{void (float*)* @_Z11somekernel1Pf, !"kernel", i32 1}
> !1 = !{void (float*)* @_Z3fooPf, !"kernel", i32 1}
>
> What are these? How to retrieve them, given eg a Module *. I've tried
> iterating over the global variables, named metadata, and aliases, but
> nothing. I'm trying:
>
> for(auto it=M->named_metadata_begin(); it != M->named_metadata_end();
> it++) {
> NamedMDNode *namedMDNode = &*it;
> cout << "namedmdnode " << namedMDNode << endl;
> cout << "name " << string(namedMDNode->getName()) << endl;
> }
>
> for(auto it=M->global_begin(); it != M->global_end(); it++) {
> GlobalVariable *global = &*it;
> cout << "global " << global << endl;
> cout << string(global->getName()) << endl;
> }
>
> for(auto it=M->alias_begin(); it != M->alias_end(); it++) {
> GlobalAlias *alias = &*it;
> cout << "alias " << alias << endl;
> cout << string(alias->getName()) << endl;
> }
>
> Result:
>
> namedmdnode 0x1655cf0
> name nvvm.annotations
> namedmdnode 0x1658a00
> name llvm.ident
> namedmdnode 0x1658c10
> name nvvm.internalize.after.link
> namedmdnode 0x1658cd0
> name nvvmir.version
> global 0x164f468
> .str
> global 0x1650ac8
> llvm.used
>
> It seems like what I want is 'annotations', because in the ll, the
> nvvm.annotations looks like:
>
> !nvvm.annotations = !{!0, !1, !2, !3, !2, !4, !4, !4, !4, !5, !5, !4}
>
> ... and that seems like it references these !0, !1 lines somehow?
>
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] libclang: Spelling on typedefs lacks namespaces
> I think you want to get the underlying type from the typedef and then
use getTypeSpelling on that result.
Hmm, I don't think so, I actually would like to keep the typedefs in my
generated code (for readability, and because it might actually resolve
to something different when the generated code is used or to something
clang specific which then fails with other compilers). Also the
underlying type could again contain typedefs with missing namespace, so
I would have to go all the way down to the canonical type (which is what
I'm actually doing currently as a workaround)...
Michael
On 09/27/2016 03:53 PM, Adam McLaughlin wrote:
Hi Michael,
I haven't used libclang much (my use case requires LibTooling) but I
think you want to get the underlying type from the typedef and then use
getTypeSpelling on that result. Basically you want to check if
CXType.kind is CXType_Typedef and if so, get the underlying type (which
in this case should be "Bar") and then call clang_getTypeSpelling on
that result.
I don't know anything about CXCursors or CXTypes so I'll leave it to you
to figure out how to get the underlying type, but hopefully this helps.
-Adam
On Tue, Sep 27, 2016 at 8:55 AM, Michael via cfe-users
mailto:cfe-users@lists.llvm.org>> wrote:
Nobody? Wrong list? Any insight in this would be greatly appreciated.
Thanks
Michael
On 08/30/2016 07:00 PM, Michael via cfe-users wrote:
Hi
Hope I picked the right place for this kind of problem, if not
please let me know.
I'm using libclang to parse header files and generate code from
them. I found that clang_getTypeSpelling() usually includes the
namespace(s) a type was declared in. However with the exception
being typedefs (and same for "using A = B"). Not sure if this is
a bug or intended behavior, but it seems at least inconsistent.
I also couldn't really find a good workaround for this. I'd have
to manually figure out all typedefs (not just pure typedefs,
they could also be template parameters or whatever) and then
their originating namespaces. This sounds a bit cumbersome and
not really straight forward.
Minimal example:
namespace foo {
class Bar {
};
typedef Bar BarDef;
}
clang_getTypeSpelling on "Bar" (kind "Record") gives: "foo::Bar"
clang_getTypeSpelling on "BarDef" (kind "Typedef") gives:
"BarDef" (<== missing "foo::")
Any idea how to solve this problem? Am I missing something?
Thanks
Michael
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
Sent from my iPhone
> On Sep 27, 2016, at 12:06 AM, Perevalov Alexey
> wrote:
>
>
>
>
>
>
>
>
> От: mehdi.am...@apple.com от имени Mehdi Amini
>
> Отправлено: 27 сентября 2016 г. 8:46
> Кому: Perevalov Alexey
> Копия: cfe-users@lists.llvm.org; llvm-...@lists.llvm.org
> Тема: Re: [llvm-dev] objc object file generated for gnustep runtime for ELF
> target is too big
>
>
>> On Sep 26, 2016, at 6:33 AM, Perevalov Alexey via llvm-dev
>> wrote:
>>
>> Dear community,
>>
>>
>> I'm using gnustep runtime -fobjc-runtime=gnustep with gnustep-libobjc2
>> (https://github.com/gnustep/libobjc2) and
>>
>> Cocotron/Chameleon.
>>
>> For following source file
>>
>> #import
>> #import
>>
>> int main(void)
>> {
>> NSString *str = [NSString stringWithCString:"TEST"];
>> NSLog(@"test object %@", str);
>> return 0;
>> }
>>
>> Compilation in xcode's clang
>
>> Which version?
>
> I think, it doesn't matter, due to with xcode's clang all fine
It does: if there is a recent regression in the compiler, it may be in Xcode 8
as well. Can you update and try?
--
Mehdi
> but if you intersting,
>
> xcrun -sdk iphoneos clang --version
> Apple LLVM version 7.0.0 (clang-700.1.76)
> Target: x86_64-apple-darwin15.0.0
> Thread model: posix
>
> also all fine with open source llvm clang if I choose ios as -fobjc-runtime,
> I got troubles only with gnustep runtime in clang+llvm-3.8.0 and 3.9.x.
>
>> —
>> Mehdi
>
>
>> xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c
>> test_foundation.m -o test_foundation_apple.o
>> gives following result:
>> 1. object file has only 3156 bytes size
>> 2. and in disassembler only main function
>> 3. the final executable will be 49992 bytes size in this case
>>
>>
>> But compilation in llvm's clang downloaded from
>> http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
>>
>> (
>> clang version 3.8.0 (tags/RELEASE_380/final)
>> Target: x86_64-apple-darwin15.0.0
>> Thread model: posix
>> )
>> gives another results:
>> 1. object file has 159044 bytes size
>> 2. in disassembler a lot of unnecessary .objc_property_list,
>> .objc_method_list, .objc_protocol_list and .objc_protocol in .bss and
>> .data section
>> 3. the final binary size is 101837 bytes size
>>
>>
>>
>> If comment in above sample #import > file and binary file in xcode compilation will be the same,
>> but size binary and object file in case of
>> clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced
>> sufficiently:
>> binary 28569 and object 36952 accordingly.
>>
>>
>>
>> Looks like all protocols from UIKit.h is placed into binary/object
>> even it's not used there.
>> I got 3.9.0 from public git (branch release_39 of clang git
>> repository) and found that all protocols interpret as definition
>> (isThisDeclarationADefinition),
>> and in CGObjCGNU.cpp it's placed into object file whenever it's used
>> or not. With the same open source compiler and -fobjc-runtime=ios
>> protocols are not putting into
>> object file even in compilation for ELF (I used -target
>> arm-linux-gnueabi).
>> I used default binutil linker, not llvm's ld.ldd, due to I have problem with
>> relocation on ARM.
>> I didn't use LTO, due to my linker doesn't have plugin support (I didnt' yet
>> recompile it).
>>
>> Could somebody point me where to solve that problem, is it AST
>> generation stage, or linkage stage or maybe it's not a problem and just LTO
>> could be solution here?
>>
>>
>>
>>
>> p.s. It's not only one issue found by me in gnustep runtime
>> generation, and I'll report these issues in next emails.
>>
>>
>>
>>
>>
>> Best regards,
>> Alexey Perevalov
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> llvm-dev Info Page
> lists.llvm.org
> To see the collection of prior postings to the list, visit the llvm-dev
> Archives. Using llvm-dev: To post a message to all the list members, send ...
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
On 26 Sep 2016, at 14:33, Perevalov Alexey via llvm-dev wrote: > > Could somebody point me where to solve that problem, is it AST > generation stage, or linkage stage or maybe it's not a problem and just LTO > could be solution here? First, please don’t expect the sizes for different runtimes to be the same (or, necessarily, to be even very close). The Mac runtimes have a bit more support from the linker for various things. To ensure that property introspection is consistent without this support, the GNUstep runtime IR generation emits property definitions in all compilation units and then uniques them later. We’re currently working on a new ABI for the GNUstep runtime that should address the size issues, but until then this looks pretty much what I’d expect. David ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
> On Sep 26, 2016, at 6:33 AM, Perevalov Alexey via llvm-dev
> wrote:
>
> Dear community,
>
>
> I'm using gnustep runtime -fobjc-runtime=gnustep with gnustep-libobjc2
> (https://github.com/gnustep/libobjc2) and
>
> Cocotron/Chameleon.
>
> For following source file
>
> #import
> #import
>
> int main(void)
>{
>NSString *str = [NSString stringWithCString:"TEST"];
>NSLog(@"test object %@", str);
>return 0;
>}
>
> Compilation in xcode's clang
Which version?
—
Mehdi
> xcrun -sdk iphoneos clang -arch armv7s -mios-version-min=6.1 -c
> test_foundation.m -o test_foundation_apple.o
> gives following result:
> 1. object file has only 3156 bytes size
> 2. and in disassembler only main function
> 3. the final executable will be 49992 bytes size in this case
>
>
> But compilation in llvm's clang downloaded from
> http://llvm.org/releases/3.8.0/clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
>
> (
> clang version 3.8.0 (tags/RELEASE_380/final)
> Target: x86_64-apple-darwin15.0.0
> Thread model: posix
> )
> gives another results:
> 1. object file has 159044 bytes size
> 2. in disassembler a lot of unnecessary .objc_property_list,
> .objc_method_list, .objc_protocol_list and .objc_protocol in .bss and
> .data section
> 3. the final binary size is 101837 bytes size
>
>
>
> If comment in above sample #import file and binary file in xcode compilation will be the same,
> but size binary and object file in case of
> clang+llvm-3.8.0-x86_64-apple-darwin compilation will be reduced
> sufficiently:
> binary 28569 and object 36952 accordingly.
>
>
>
> Looks like all protocols from UIKit.h is placed into binary/object even
> it's not used there.
> I got 3.9.0 from public git (branch release_39 of clang git repository)
> and found that all protocols interpret as definition
> (isThisDeclarationADefinition),
> and in CGObjCGNU.cpp it's placed into object file whenever it's used or
> not. With the same open source compiler and -fobjc-runtime=ios
> protocols are not putting into
> object file even in compilation for ELF (I used -target
> arm-linux-gnueabi).
> I used default binutil linker, not llvm's ld.ldd, due to I have problem with
> relocation on ARM.
> I didn't use LTO, due to my linker doesn't have plugin support (I didnt' yet
> recompile it).
>
> Could somebody point me where to solve that problem, is it AST
> generation stage, or linkage stage or maybe it's not a problem and just LTO
> could be solution here?
>
>
>
>
> p.s. It's not only one issue found by me in gnustep runtime generation,
> and I'll report these issues in next emails.
>
>
>
>
>
> Best regards,
>Alexey Perevalov
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] libclang: Spelling on typedefs lacks namespaces
I had a look into the clang sources. It seems this little patch would
"fix" the problem. This was pure guess work, I don't know what
consequences this might have.
Index: lib/AST/TypePrinter.cpp
===
--- lib/AST/TypePrinter.cpp (revision 282393)
+++ lib/AST/TypePrinter.cpp (working copy)
@@ -96,7 +96,7 @@
static bool canPrefixQualifiers(const Type *T, bool
&NeedARCStrongQualifier);
void spaceBeforePlaceHolder(raw_ostream &OS);
-void printTypeSpec(const NamedDecl *D, raw_ostream &OS);
+void printTypeSpec(NamedDecl *D, raw_ostream &OS);
void printBefore(const Type *ty, Qualifiers qs, raw_ostream &OS);
void printBefore(QualType T, raw_ostream &OS);
@@ -794,7 +794,14 @@
printAfter(T->getReturnType(), OS);
}
-void TypePrinter::printTypeSpec(const NamedDecl *D, raw_ostream &OS) {
+void TypePrinter::printTypeSpec(NamedDecl *D, raw_ostream &OS) {
+
+ // Compute the full nested-name-specifier for this type.
+ // In C, this will always be empty except when the type
+ // being printed is anonymous within other Record.
+ if (!Policy.SuppressScope)
+AppendScope(D->getDeclContext(), OS);
+
IdentifierInfo *II = D->getIdentifier();
OS << II->getName();
spaceBeforePlaceHolder(OS);
Thanks
Michael
On 09/27/2016 02:55 PM, Michael via cfe-users wrote:
Nobody? Wrong list? Any insight in this would be greatly appreciated.
Thanks
Michael
On 08/30/2016 07:00 PM, Michael via cfe-users wrote:
Hi
Hope I picked the right place for this kind of problem, if not please
let me know.
I'm using libclang to parse header files and generate code from them.
I found that clang_getTypeSpelling() usually includes the
namespace(s) a type was declared in. However with the exception being
typedefs (and same for "using A = B"). Not sure if this is a bug or
intended behavior, but it seems at least inconsistent. I also
couldn't really find a good workaround for this. I'd have to manually
figure out all typedefs (not just pure typedefs, they could also be
template parameters or whatever) and then their originating
namespaces. This sounds a bit cumbersome and not really straight
forward.
Minimal example:
namespace foo {
class Bar {
};
typedef Bar BarDef;
}
clang_getTypeSpelling on "Bar" (kind "Record") gives: "foo::Bar"
clang_getTypeSpelling on "BarDef" (kind "Typedef") gives: "BarDef"
(<== missing "foo::")
Any idea how to solve this problem? Am I missing something?
Thanks
Michael
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big
От: Dr D. Chisnall от имени David Chisnall Отправлено: 27 сентября 2016 г. 10:42 Кому: Perevalov Alexey Копия: cfe-users@lists.llvm.org; llvm-...@lists.llvm.org Тема: Re: [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big On 26 Sep 2016, at 14:33, Perevalov Alexey via llvm-dev wrote: > > Could somebody point me where to solve that problem, is it AST > generation stage, or linkage stage or maybe it's not a problem and just LTO > could be solution here? >First, please don’t expect the sizes for different runtimes to be the same >(or, necessarily, to be even very close). The Mac runtimes have a bit more >support from the linker for >various things. To ensure that property >introspection is consistent without this support, the GNUstep runtime IR >generation emits property definitions in all compilation units and >then >uniques them later. >We’re currently working on a new ABI for the GNUstep runtime that should >address the size issues, but until then this looks pretty much what I’d expect. >David Thank you David, I didn't expect the same size for executable file, but I got binary (real application) for gnustep runtime 5 times bigger than for ios runtime, and then I decided to figure out it. (neither -flto nor -fdata-sections -ffunction-sections -Wl,--gc-sections helped). 5x bigber it's not due to only this issue ;) I think. For small sample (listed above in thread) I found that all protocol's declaration is interprets as definitions, and I see a lot of .objc_protocol: .long 3 .long .L.objc_protocol_name .long .objc_protocol_list .long .objc_method_list .long .objc_method_list.1 .long .objc_method_list.2 .long .objc_method_list.3 .long .objc_property_list .long .objc_property_list.4 .size .objc_protocol, 36 .type .L__unnamed_37,%object @ @34 .section.rodata.str1.1,"aMS",%progbits,1 .L__unnamed_37: .asciz "copyWithZone:" .size .L__unnamed_37, 14 .type .L__unnamed_38,%object @ @35 ... in disassembler output and in final binary, but these protocol aren't used in sample. Neither front end nor linker got rid of it. You wrote definitions will be unique, but it didn't strip out unnecessary .objc_protocol and depended fields. (frankly saying after strip -s I didn't see .objc_protocol, but still find all selector and protocol names in strings output ;) And it's look like a bug. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] libclang: Spelling on typedefs lacks namespaces
While it generates some ugly code I found it easier to simply use the
canonical names for all types. I spent tens of hours fighting this and
never found a good way.
On Tuesday, September 27, 2016, Michael via cfe-users <
cfe-users@lists.llvm.org> wrote:
> Nobody? Wrong list? Any insight in this would be greatly appreciated.
>
> Thanks
>
> Michael
>
> On 08/30/2016 07:00 PM, Michael via cfe-users wrote:
>
>> Hi
>>
>> Hope I picked the right place for this kind of problem, if not please let
>> me know.
>>
>> I'm using libclang to parse header files and generate code from them. I
>> found that clang_getTypeSpelling() usually includes the namespace(s) a type
>> was declared in. However with the exception being typedefs (and same for
>> "using A = B"). Not sure if this is a bug or intended behavior, but it
>> seems at least inconsistent. I also couldn't really find a good workaround
>> for this. I'd have to manually figure out all typedefs (not just pure
>> typedefs, they could also be template parameters or whatever) and then
>> their originating namespaces. This sounds a bit cumbersome and not really
>> straight forward.
>>
>> Minimal example:
>>
>> namespace foo {
>> class Bar {
>> };
>> typedef Bar BarDef;
>> }
>>
>> clang_getTypeSpelling on "Bar" (kind "Record") gives: "foo::Bar"
>> clang_getTypeSpelling on "BarDef" (kind "Typedef") gives: "BarDef" (<==
>> missing "foo::")
>>
>> Any idea how to solve this problem? Am I missing something?
>>
>> Thanks
>>
>> Michael
>> ___
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>>
>
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
