Re: Accessibility of name mangling utilities

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Accessibility of name mangling utilities

Anton Lokhmotov
> In our application we would like to reuse part of the name mangling
> utilities provided by clang.

Yes, that would be good but I guess would require more re-engineering than
simply moving the corresponding header files.  When I needed to use name
mangling, I had to reverse engineer the current implementation for the cases
I cared about and re-implement it from scratch.

Anton/L.

> ------------------------------
>
> Message: 3
> Date: Wed, 05 May 2010 11:47:30 +0200
> From: Enea Zaffanella <[hidden email]>
> Subject: [cfe-dev].
> To: "[hidden email]" <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello.
>
> In our application we would like to reuse part of the name mangling
> utilities provided by clang. We saw in the developer documentation that
> a class providing appropriate entry points (clang::MangleContext) is
> defined in lib/CodeGen/Mangle.h and therefore is not accessible from
> code using clang as a library.
>
> Would it be possible to move header files lib/CodeGen/Mangle.h and
> lib/CodeGen/CGCXX.h into directory include/clang/CodeGen?
>
> Regards,
> Enea Zaffanella.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Accessibility of name mangling utilities

Douglas Gregor

On May 12, 2010, at 5:29 AM, Anton Lokhmotov wrote:

>> In our application we would like to reuse part of the name mangling
>> utilities provided by clang.
>
> Yes, that would be good but I guess would require more re-engineering than
> simply moving the corresponding header files.  When I needed to use name
> mangling, I had to reverse engineer the current implementation for the cases
> I cared about and re-implement it from scratch.


Moving the functionality out of CodeGen and into more accessible headers (say, in the AST library) is relatively easy and should be done soon.

It would be a shame if you were forced to rewrite all of name mangling because of some limitations in the current implementation. The code is complex enough and is tied to a de facto standard, so it shouldn't be duplicated unless it is absolutely necessary. Could you explain why you had to re-implement name mangling for your task?

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Accessibility of name mangling utilities

Anton Lokhmotov
> -----Original Message-----
> From: Douglas Gregor [mailto:[hidden email]]
> Sent: 12 May 2010 16:39
> To: Anton Lokhmotov
> Cc: [hidden email]
> Subject: Re: [cfe-dev] Accessibility of name mangling utilities

> It would be a shame if you were forced to rewrite all of name mangling
> because of some limitations in the current implementation.
The real limitation was exactly that the functionality was hidden inside
CodeGen.

> Could you explain why you had to re-implement name mangling for your task?
I was working on a prototype and just wanted to have something working in
under a day (hence, I wasn't forced to rewrite all of name mangling).  I
hope that when it comes to proper software engineering, the functionality
will be accessible.

BTW, perhaps it's time to bring up a limitation of the name mangling scheme
I found.  Namely, name mangling for vector functions doesn't take into
account the vector length.  For example, given declarations:

__attribute__((overloadable))  float8 select(float8,  float8,  int8);
__attribute__((overloadable)) float16 select(float16, float16, int16);

Clang produces only one LLVM declaration depending on whether in source code
a call to the 8-element version comes first or a call to the 16-element
version comes first.  If a call to the 8-element version comes first, the
declaration is:

declare <8 x float>
        @_Z6selectU8__vectorfS_U8__vectori(<8 x float>, <8 x float>, <8 x
i32>)

If, however, a call to the 16-element version comes first, the declaration
is:

declare <16 x float>
        @_Z6selectU8__vectorfS_U8__vectori(<16 x float>, <16 x float>, <16 x
i32>)


In the former case, the calls look like:

; call for 8-element operands
%call8 = call <8 x float> @_Z6selectU8__vectorfS_U8__vectori(<8 x float>
%Vf8_0, <8 x float> %Vf8_1, <8 x i32> %Vi8) nounwind
...
; call for 16-element operands
%call16 = call <16 x float> bitcast (<8 x float> (<8 x float>, <8 x float>,
<8 x i32>)* @_Z6selectU8__vectorfS_U8__vectori to <16 x float> (<16 x
float>, <16 x float>, <16 x i32>)*)(<16 x float> %Vf16_0, <16 x float>
%Vf16_1, <16 x i32> %Vi16) nounwind


In the latter case, the calls look like:

; call for 16-element operands
%call16 = call <16 x float> @_Z6selectU8__vectorfS_U8__vectori(<16 x float>
%Vf16_1, <16 x float> %Vf16_2, <16 x i32> %Vi16)
...
; call for 8-element operands
%call8 = call <8 x float> bitcast (<16 x float> (<16 x float>, <16 x float>,
<16 x i32>)* @_Z6selectU8__vectorfS_U8__vectori to <8 x float> (<8 x float>,
<8 x float>, <8 x i32>)*)(<8 x float> %Vf8_0, <8 x float> %Vf8_1, <8 x i32>
%Vi8) nounwind


In either case, a call to the version that has no declaration involves
bitcast of the function pointer with unclear semantics.  Is this really as
bad as it seems?

Anton L.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev