search for: copyaggregate

...I don't think I introduced it (was it Devang?). >> >> Yup. PR 1278 > > Ok! Can you please fix it to index by GCC type? There is a many to > one mapping between gcc types and llvm types. This is tricky and probably won't work. Padding info is in llvm struct type and CopyAggregate() is operating on llvm type. There is not any way to map llvm type back to gcc type. Am I missing something ? - Devang

...t (was it Devang?). >>> >>> Yup. PR 1278 >> >> Ok! Can you please fix it to index by GCC type? There is a many to >> one mapping between gcc types and llvm types. > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? I don't think so, I have reached the same conclusion. You can pass the gcc type into CopyAggregate, but it's recursive, and there's no way to get the gcc type for t...

On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> Alternatively I can take the Padding bit into account in the >>>> StructType::get code somehow. Anyone have a strong opinion? >>> >>> Shouldn't it be a map from the gcc type to the padding info? >>> That said, you can get

...ligned (8))) void * a; } ; The second example is padded out to 8 bytes, so both of these look like { i8 *, [1 x i32] } This leads the "struct type factory" StructType::get to think they are the same. But, the second field is marked as Padding in the second case but not the first, and CopyAggregate does not copy Padding. When the second type goes through ConvertType, it is converted to the same llvm Type as the first type, and the StructTypeConversionInfo info is replaced; later copies of the first type then think they don't have to copy the padding, producing wrong code. I'm in...

...s it Devang?). > >> > >> Yup. PR 1278 > > > > Ok! Can you please fix it to index by GCC type? There is a many to > > one mapping between gcc types and llvm types. > > This is tricky and probably won't work. Padding info is in llvm struct > type and CopyAggregate() is operating on llvm type. There is not any > way to map llvm type back to gcc type. Am I missing something ? > > - > Devang > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 15 Feb 2008 11:21:41 -0800 > From: Chris Lattner <sabre...

...t;>> Yup. PR 1278 >>> >>> Ok! Can you please fix it to index by GCC type? There is a many to >>> one mapping between gcc types and llvm types. >> >> This is tricky and probably won't work. Padding info is in llvm >> struct >> type and CopyAggregate() is operating on llvm type. There is not any >> way to map llvm type back to gcc type. Am I missing something ? > > > I don't think so, I have reached the same conclusion. You can pass > the gcc type into CopyAggregate, but it's recursive, and there's no > wa...

> How about this patch then? How about this one :) It passes alignment and volatility around with DestLoc. It's not finished because I noticed some bugs in how CopyAggregate and ZeroAggregate handle alignment (problem points marked with "QQ"). Also, I noticed potential problems with how we handle call arguments and return results (what if they are strangely aligned/volatile?), marked with FIXME. While there, I fixed the following: - Taught EmitAggregateZero...

...gt; >> Yup. PR 1278 > > > > > > Ok! Can you please fix it to index by GCC type? There is a many to > > > one mapping between gcc types and llvm types. > > > > This is tricky and probably won't work. Padding info is in llvm struct > > type and CopyAggregate() is operating on llvm type. There is not any > > way to map llvm type back to gcc type. Am I missing something ? > > > > - > > Devang > > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: F...

How about this patch then? -bw Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 43658) +++ gcc/llvm-convert.cpp (working copy) @@ -758,7 +758,7 @@ } -Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) { +Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) {

...e second example is padded out to 8 bytes, so both of these look like > { i8 *, [1 x i32] } > This leads the "struct type factory" StructType::get to think they are > the same. > But, the second field is marked as Padding in the second case but not > the first, > and CopyAggregate does not copy Padding. When the second type > goes through ConvertType, it is converted to the same llvm Type as the > first type, > and the StructTypeConversionInfo info is replaced; later copies of the > first type > then think they don't have to copy the padding, producin...

...at free.fr> wrote: > > How about this patch then? > > How about this one :) Your patch didn't apply cleanly, so I couldn't test it out. :-( -bw > It passes alignment and volatility around > with DestLoc. It's not finished because I noticed some bugs in > how CopyAggregate and ZeroAggregate handle alignment (problem points > marked with "QQ"). Also, I noticed potential problems with how we > handle call arguments and return results (what if they are strangely > aligned/volatile?), marked with FIXME. > > While there, I fixed the following: &g...