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

Duncan Sands baldrick at free.fr
Mon Jul 26 07:31:44 PDT 2010


Hi Xiaolong,

> 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.

I think on the contrary this is llvm-g++ trying to obtain ABI conformance.
The rules on how parameters should be passed to functions (in registers, on
the stack, partly in registers, partly on the stack) can be quite complicated.
Rather than pushing this complexity into LLVM, front-ends are required to take
care of ensuring ABI conformance when they generate the LLVM IR.  The kind of
transform you see looks typical of llvm-g++ trying to handle an ABI rule which
says that initial fields of a struct should be passed in registers.  In short,
I don't think this is LLVM doing an optimization, it is LLVM trying to produce
correct ABI conformant code.

>>> 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?

I think you will find that this is not really the case, it is just that g++ does
this when transforming gimple to RTL (llvm-g++ does it when transforming gimple
to LLVM IR, which is in fact quite analogous).  If you look at the final
assembler generated by g++ it should be equivalent to what llvm-g++ produces.

Ciao,

Duncan.



More information about the llvm-dev mailing list