llvm dev - Jul 2010 - [LLVMdev] How to disable simplifying function parameters in llvm-g++

Hello everybody, 

It seems to me that there is one kind of default optimization
executed by llvm-g++, simplifying function parameters in certain
cases. Consider the following example:

Given an iterator (in the context of C++ STL) (i.e. a class containing
a pointer to another class):

  %"struct.std::_List_const_iterator<int>" = type {
%"struct.std::_List_node_base"* }
  (The form in the readable LLVM language)

and a function definition (declaration):

  void _M_insert(iterator __position, const value_type& __x) { ... }

By issuing this command:

  llvm-g++ -fno-exceptions -fno-inline -emit-llvm -c ...

The compilation substitutes "__position.0" for "__position",
as shown below:

  define linkonce_odr void
@_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int>
>"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... }

My questions are:
Could this transformation be disabled in llvm-g++? And how to achieve this?

P.S. Without any optimizations, g++ does NOT do this.

Best, 
Xiaolong

Hi Xiaolong,
> The compilation substitutes "__position.0" for
"__position", as shown below:
>
>    define linkonce_odr void
@_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int>
>"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... }
names like this only exist to make the LLVM IR more readable, and have no
effect on the final assembler.  If you want to find out original parameter
names you need to use debug info.
> P.S. Without any optimizations, g++ does NOT do this.
It's unclear to me what you mean here, since there are no names of this kind
in
the assembly files produced by g++.  Are you perhaps referring to the name g++
prints in tree dumps?

Ciao,

Duncan.

Thanks, Duncan.
> > The compilation substitutes "__position.0" for
"__position", as shown below:
> >
> >    define linkonce_odr void
@_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int>
>"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... }
> 
> names like this only exist to make the LLVM IR more readable, and have no
> effect on the final assembler.  If you want to find out original parameter
> names you need to use debug info.
Note that the original parameter (of the function in concern) is of
type "struct.std::_List_const_iterator<int>", whereas the
parameter
(after the compilation) is of type
"struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the
original parameter with its sole field. This is understandable and the
LLVM output indicates this by using "__position.0" rather than
"__position". Further, llvm-g++ represents (bitcasts) the parameter
type "struct.std::_List_node_base"* as (into) i64.  Though this may
be decoded by analyzing the meta data with the function, I believe
that llvm-g++ has conducted some transformations somehow. To me, the
transformation looks likes scalar replacement.

To further understand such behavior (of llvm-g++), let's image that we
augment the above type "struct.std::_List_const_iterator<int>"
with
one more dummy field. As a result, llvm-g++ replaces the original
parameter with two individual parameters which are the two fields of
the original parameter, illustrated as below.

 (..., i64 %__position.0, i64 %__position.1, i32 %data) nounwind ssp { ... }
> > P.S. Without any optimizations, g++ does NOT do this.
> 
> It's unclear to me what you mean here, since there are no names of this
kind in
> the assembly files produced by g++.  Are you perhaps referring to the name
g++
> prints in tree dumps?
Yes. My discussion only focuses on the front-end output. As to the
example in question, g++ preserves the original function parameter,
without replacing the parameter with its sole field. Is this clear
enough?

Best, 
Xiaolong