[llvm-commits] [llvm-gcc-4.2] r62076 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

Evan Cheng echeng at apple.com
Tue Jan 13 14:48:58 PST 2009


On Jan 13, 2009, at 3:52 AM, Duncan Sands wrote:

> Hi Evan,
>
>> Load / store alignments should be the alignments of the memory  
>> object used to construct the LValue, not the alignments of the  
>> values being loaded / stored.
>
> I've reverted this because it was causing several failures in the
> testsuite, and also broke the Ada build.  Also, I don't see how this
> approach can work without major changes.  Consider the following part
> of your patch:
>
>> @@ -5956,8 +5975,10 @@
> ...
>>   } else {
>>     ArrayAddr = Emit(Array, 0);
>> +    ArrayAlign = expr_align(ArrayTreeType) / 8;
>>   }
>
> This is the case of when we are doing "a[i]", where "a" is a pointer.
> There's no reason to think that "a" points to aligned memory, so
> using the type alignment is wrong.  So where to get the alignment
> from?  We get the pointer "a" from Emit, which doesn't provide  
> alignment
> info for the pointee.  As far as I can see either Emit needs to return
> more info (complicated to implement) or we need to dig down into the  
> gcc
> tree to get the underlying object and extract its alignment.  In other
> words, we need to do what we expected expr_align to do (only it  
> wasn't).
> I think we should just make expr_align more intelligent.  Since we  
> are the
> only users of it, there is no danger involved in changing it.

This gets translated into low level pointer arithmetics, right? Later  
on llvm-convert casts it to i8*:

ArrayAddr = BitCastToType(ArrayAddr,  
PointerType::getUnqual(Type::Int8Ty));

Is there a reason why we can't just give it the alignment of i8?

Evan

>
>
> Ciao,
>
> Duncan.
>
> PS: I didn't check, but presumably this same problem occurs elsewhere:
> we get a pointer from Emit and need alignment for the pointee.




More information about the llvm-commits mailing list