[LLVMdev] [global-isel] Type-independence of load/store

[Jakob Stoklund Olesen]

On Aug 9, 2013, at 5:12 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Sounds like a really exciting topic; I'd love to be involved in
> implementation.

We need all the volunteers we can get. ;)

>> On the other hand, when types are not used to select register banks, it
>> becomes really difficult to explain the difference between load i32 and load
>> f32. The hardware doesn't care either, it simply knows how to load 32 bits
>> into a given register.
> 
>> We can use a three-level hierarchical type system to
>> better describe this:
> 
> That may be something we want to be flexible about. I know we don't
> support big-endian ARM at the moment, but its NEON load/store
> instructions do take an interest in more than just the total number of
> bits I think.
> 
>        vst1.16 {d0}, [r0]
>        vst1.64 {d0}, [r0]
> would give byte-wise layouts of
>        1 0 3 2 5 4 7 6
>        7 6 5 4 3 2 1 0
> 
> Other big-endian targets may have similar issues, but I know virtually
> nothing about them.

ARM’s is an interesting implementation of big-endian vectors. AFAIK, other architectures go all in and use both big-endian lanes and elements. That makes the problem go away, and you only need one load instruction.

Note that LLVM IR requires a bitcast to be equivalent to storing one type and loading the other, and it seems that this would turn a bitcast into a kind of shuffle.

I think Dan has opinions on this particular topic.

Thanks,
/jakob