[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