[llvm-commits] [llvm] r91614 - in /llvm/trunk: include/llvm/CodeGen/ValueTypes.h lib/CodeGen/SelectionDAG/LegalizeDAG.cpp

Ken Dyck Ken.Dyck at onsemi.com
Wed Jan 6 07:46:34 PST 2010


On Wednesday, January 06, 2010 6:15 AM, Duncan Sands wrote:
>
> > Introduce EVT::getHalfSizedIntegerVT() for use in 
> > ExpandUnalignedStore() in LegalizeDAG.cpp. Unlike the code it 
> > replaces, which simply decrements the simple type by one, 
> > getHalfSizedIntegerVT() searches for the smallest simple 
> integer type 
> > that is at least half the size of the type it is called on. This 
> > approach has the advantage that it will continue working if a new 
> > value type (such as
> > i24) is added to MVT.
> 
> I don't think this is correct.  

Now that you point it out, me neither. Thanks for the review!

> How about rewriting ExpandUnalignedStore so that it 
> works as follows.  First it finds the largest legal integer 
> type T with the given alignment (eg: i8 for alignment 1, i16 
> for alignment 2) that is smaller than the original type.  It 
> then does the maximum possible number of T stores.
> If the entire value wasn't stored then replace the original 
> type with the left over bits and repeat.  

Okay. I'll take a stab at implementing this.

It looks like ExpandUnalignedLoad might need similar logic, btw.

> For example, 
> suppose i8 has alignment 1, i16 alignment 2,
> i24 alignment 2, i32 alignment 4 and i48 alignment 4, and 
> that all these types are legal.  Then a store of i48 with 
> alignment 2 would be expanded into two
> i24 stores, a store of i64 with alignment 2 would be expanded 
> into two i32 stores, 

Perhaps I'm misunderstanding, but with this approach, wouldn't a store
of i64 with an alignment of 2 expand to two i24 stores and one i16 store
since the largest legal type of alignment 2 is i24? (Presumably the one
unaligned i24 store would need to be further expanded to an i16 and an
i8 store). 

A store of an i64 with an alignment of 4 would result in two i32 stores.
Is that what you meant?

> Another flaw is that getHalfSizedIntegerVT may return illegal 
> simple types when you would really rather use legal ones.  

Yes. My aim was to replicate the old behaviour, which could also result
in an illegal simple type. But I agree that it would be better to avoid
illegal types.


-Ken





More information about the llvm-commits mailing list