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

[Duncan Sands]

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

Ciao,

Duncan.