[cfe-commits] r55311 - /cfe/trunk/lib/CodeGen/CGExprScalar.cpp

[Daniel Dunbar]

Yes, I'm not happy with this solution but not sure of the right one.

On the one hand we are low enough in CG that the issues with other
types probably aren't a concern. If you call EmitScalarConversion
on a (llvm) pointer value and are converting to something with a pointer
value then you should get a bitcast, period (I think).

On the other hand, it feels like this is relying heavily on Sema and other
parts of CG doing the "right thing" and is embedding assumptions.

I'm okay with adding a predicate to Type but its not really clear to me yet
what the semantics of it are supposed to *mean*, and when it should
be used. Another approach would be to not do the checks in terms of
LLVM types and instead use isa<ObjCQualifiedIdType>.

The weirdness here is that  id has struct xxx * as its canonical type, while
id<X>
has no canonical type. Perhaps we should have a getEffectiveCanonicalType()
which embeds the distinction between the canonical type which the source
code
can end up with access to, and the "effective" canonical type which is the
underlying representation of a type.

 - Daniel

On Mon, Aug 25, 2008 at 10:08 AM, Chris Lattner <clattner at apple.com> wrote:

>
> On Aug 25, 2008, at 2:51 AM, Daniel Dunbar wrote:
>
>  Author: ddunbar
>> Date: Mon Aug 25 04:51:32 2008
>> New Revision: 55311
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=55311&view=rev
>> Log:
>> Do is-a-pointer checks in terms of LLVM types in
>> EmitScalarConversion().
>> - Important for allowing Obj-C void * to id<X> casts and so on.
>> - Not sure about this fix however, perhaps Type should understand
>>  that id is effectively a pointer type.
>>
>
> This is a bit tricky, don't arrays and vlas decay to llvm pointers?  Maybe
> it would be better to add a new predicate to Type.
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20080825/c3943131/attachment.html>