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

[Evan Cheng]

On Jan 15, 2009, at 1:13 AM, Duncan Sands wrote:

> Hi Evan,
>
>> Right. I am saying for array_ref that is turned into pointer
>> arithmetics + load / store i8, just return lvalue with alignment 1.  
>> It
>> is always correct. The down size I see if theoretically this could
>> prevent some optimization that combine multiple loads / stores into a
>> larger one. I think we can eliminate most of these potential cases by
>> calling getPointerAlignment() when the type is POINTER_TYPE.
>>
>> The main issue is I'd like to fix the bug where we emit memory
>> instructions with artificially high alignment. But I am willing to
>> invest a significant effort to change Emit. I'll cook up with another
>> patch with those x86-64 linux (which obviously hates me) failures  
>> fixed.
>
> I think your lvalue scheme is better for the long run than my  
> expr_align
> one.  However, for testing purposes I think it would be a good idea  
> to also
> enhance expr_align and compare the results of the two schemes.  As  
> well as

I am not going to enhance expr_align for two reasons 1) no time :-)    
2) my assumptions / understanding are still the same so whatever  
mistake there may be in the LValue patch is likely to be in expr_align.

>
> catching mistakes, this may help find places where the alignment  
> produced
> is suboptimal.  As for "Emit", this should not be changed if it can be
> avoided.  Better to emit an alignment of 1 in tricky cases and have  
> the
> LLVM optimizers improve it.  Also, you use the alignment of LLVM types
> in some places IIRC.  This is not great because (1) I think  
> currently LLVM
> types may be more aligned than the corresponding gcc types (I want  
> to fix
> this some day); (2) LLVM types can certainly be less aligned than  
> the gcc
> type, which means you are using a suboptimal value.  Finally, I  
> think you

Ok.

>
> have to be very careful in using type alignment at all.  Type  
> alignment is
> great when declaring variables - it gives the default alignment to  
> use for
> the allocated memory; this default can of course be overridden.   
> However it
> is basically useless for the purposes of loads and stores: there you  
> need
> to estimate the minimum alignment that the storee is *guaranteed* to  
> have.
> Knowing that the storee has a certain type doesn't guarantee  
> anything about
> it's alignment at all!  What is reliable is alignment of objects,  
> i.e. the
> result of DECL_ALIGN.  So I think that anywhere you can't get  
> alignment from
> an object, you shouldn't use the type alignment, you should use 1  
> instead.

Ok.

I'll check in a new patch soon. Please test Ada build (I am sure you  
will).

Evan
>
>
> Ciao,
>
> Duncan.