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

Evan Cheng evan.cheng at apple.com
Thu Jan 15 18:21:39 PST 2009

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


> 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.


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

> Ciao,
> Duncan.

More information about the llvm-commits mailing list