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

[Bill Schmidt]

On Mon, 2013-01-28 at 10:49 -0800, John McCall wrote:
> 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.)

Ah, brilliant!  Yes, that solves my concern.  Revised patch attached.  I
ended up moving handleComplexIntConversion below handleIntConversion to
avoid forward declarations, but this shouldn't make the patch too hard
to read since there isn't much left of the original version of the
former.

I had forgotten function pointers can be used as template arguments.
This is a nice trick that I will file away for future use.

Thanks,
Bill
> 
> John.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex-convert-2013-01-28b.patch
Type: text/x-patch
Size: 67158 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130128/c3fdaed3/attachment.bin>