[cfe-commits] [PATCH, RFC] Fix PR14881 (complex integer promotion rules)

John McCall rjmccall at apple.com
Mon Jan 28 10:49:09 PST 2013


On Jan 28, 2013, at 6:58 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote:
>> Something along these lines, but I'd really prefer if you could somehow
>> re-use the logic from handleIntegerConversion.  I think you could if you
>> just made that function take function pointers to do the casts on the left
>> and right parameters:
>> 
>> typedef ExprResult PerformCastFn(Sema &S, Expr *operand, QualType toType);
>> static QualType handleIntegerConversion(Sema &S, ExprResult &LHS,
>>                                       ExprResult &RHS, QualType LHSType,
>>                                       QualType RHSType, bool IsCompAssign,
>>                                       PerformCastFn *doLHSCast, PerformCastFn *doRHSCast)
>> 
>> The current use would just use a function like this:
>> ExprResult doIntegralCast(Sema &S, Expr *op, QualType toType) {
>>   return S.ImpCastExprToType(op, toType, CK_IntegralCast);
>> }
>> 
>> But whenever an operand is complex, you'd instead use:
>> ExprResult doComplexIntegralCast(Sema &S, Expr *op, QualType toType) {
>>   return S.ImpCastExprToType(op, S.Context.getComplexType(toType), CK_ComplexIntegralCast);
>> }
>> 
>> John.
> 
> Hm, ok, if you prefer.  My intent was to avoid any slowdown to the
> common case of scalar integer conversion.  Complex integer is a GNU
> extension used by -- well, practically nobody.  We need to support it
> for completeness, but its use will be rare.  Using indirect calls incurs
> some performance penalty, so I chose to leave the existing code alone.
> But if you like, I'll cobble this up and see what it looks like.
> 
> (Sorry for losing the conversation threadedness; my mail server was down
> over the weekend and I lost some messages, yours included...)

I agree that this is a reasonable concern.  At the same time, I'd like to not
end up with a multitude of different code here just for computing the
common type of two integers!

Fortunately, we are working in C++, so this is easy to fix fairly cleanly:
instead of making a function which takes the function pointers as arguments,
make a function template which takes the function pointers as template
arguments.  They are basically guaranteed to be inlined this way.

(I believe you'll have to put the helper functions in an anonymous namespace,
instead of making them static, in order to placate the C++98 restriction about
template arguments with formally internal linkage.)

John.



More information about the cfe-commits mailing list