[cfe-dev] struct copy

[Chris Lattner]

On Sep 29, 2008, at 3:14 AM, Matthijs Kooijman wrote:

> Hi Chris,
>
>>> Ah ok, "unions as the biggest field" is bad. How about if we
>>> consider unions as arrays (as clang does):
>>>
>>>  %struct.a = type { i8, double }
>>>  %struct.c = type [12 x i8]
>> That would solve this problem, but also isn't a universally good  
>> thing
>> to do.  Doing things like this can break the (critical for some  
>> codes)
>> Scalar Replacement of Aggregates optimization.
> Can you give an actual example of this? By my reasoning, if a struct  
> is really
> part of a union, and the value is thus used in some other way,  
> scalarrepl
> wouldn't be able to split it up anyway, right?

Right.  By picking one of the types though, you do catch the case  
where the union is only used as that type.

> If an alloca of a union is in fact only used as its struct type and  
> never as
> any of the other types, then instcombine will change the i8 array  
> alloca to
> a struct alloca and scalarrepl will still be able to do its work  
> just fine.

Hrm... this is a big maybe.  The instcombine xform has a lot of  
constraints on it.

>> In general, it is good  for the front-end to preserve as much  
>> accurate type
>> info in the LLVM  IR as possible.
> I agree with you here. However, I'm not so sure that picking one  
> type a union
> can become over another, is much more accurate than just picking an  
> i8 array
> always.

Why is there so much focus on this?  Is there a specific problem  
you're trying to solve?  There are lots of real problems to tackle  
too :)

-Chris