[cfe-dev] AST Representation of Conversions

[steve naroff]

On Jul 28, 2009, at 3:03 PM, Sebastian Redl wrote:
>
> Essentially, I think, we will have to enhance or wrap
> ImplicitConversionSequence from SemaOverload.h to also be able to
> represent conversions that are only explicitly possible. Then we put  
> it
> into the AST library and give CastExpr one of those.
> The problem with this approach is that it is heavy.
> ImplicitConversionSequence is a heavy object (40 bytes on 32-bit  
> without
> considering alignment, 80 bytes on 64-bit if alignment works the way I
> think it does), and every single ImplicitCastExpr (think of all the
> "usual integral conversions" in C) would bear this weight, as would
> casts that don't need this information, like const_cast (noop to
> codegen), dynamic_cast (always runtime calls) and reinterpret_cast
> (always bitcast).
> An option would be to rearrange the hierarchy, but this makes it  
> reflect
> the implementation instead of the logical grouping. Currently the
> hierarchy makes sense to programmers:
> http://clang.llvm.org/doxygen/classclang_1_1CastExpr.html
> If we were to rearrange it to fit the needs of data storage, CastExpr
> would be the direct base of CXXConstCastExpr, CXXDynamicCastExpr,
> CXXReinterpretCastExpr and ComplexCastExpr. ComplexCastExpr would hold
> the conversion sequence and be the base of CXXStaticCastExpr,
> CXXFunctionalCastExpr, CStyleCastExpr and ImplicitCastExpr. Not  
> pretty.
>
> Does anyone else have suggestions on how to solve this problem?
>

Hi Sebastian,

 From my perspective, ExplicitCastExpr models the language and  
ImplicitCastExpr models aspects of the underlying implementation (AST  
nodes inserted by Sema to simplify the code generator). IIRC, CastExpr  
is abstract. I think this division is nice/clean.

Would it make sense to add "heavier" sub-classes of ImplicitCastExpr  
to model the C++-specific conversions? Would this avoid the space  
overhead you are talking about?

I'm just starting to get my feet wet with clang's C++ support, so I  
don't have any C++-specific insights.

snaroff


> Sebastian
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev