[LLVMdev] [Patch][RFC] Change R600 data layout

[Jon Pry]

On Tue, Dec 31, 2013 at 6:04 PM, Micah Villmow
<micah.villmow at smachines.com> wrote:
> Mostly n64 is there for historical reasons as AMDGPU backend originally derived from the AMDIL backend. The AMDIL backend did support 64bit native types on some hardware chips of the r6XX derived architectures, so for simplicity software efficiently emulated them on the ones it did not.
>
> Also GCN does support 64bit on many operations, so I wouldn't remove it as a native type there.
>
> Basically what you want to for clang to emit better code is to use per pointer address spaces. So in the address spaces where you want 32bit computation, you specify it in the data layout, and in the address spaces where you need 64bit, you do the same. LLVM produces the right code in these situations.

I don't believe this is a viable option. The address space in question
is (1) global, which is set to p64 as it must be. The address space
computation is not an issue. It's this senseless promotion of the
indexer to 64 bits. Thus requiring the i++ to be a 64bit add and so
on.


> This isn’t entirely true. 64-bit operations do exist for a small number of (mostly bitwise) operations, just not the normal arithmetic add and multiply. Most importantly, there are 64-bit loads and stores. I’ve seen various places that use the native integer type to
> decide a good sized integer for something like memcpy. It would be beneficial to use a 64-bit type for a series of load / store for global pointers.

I agree that it would be nice if user code could somehow tell that
64bit ld/s was optimal. Imho the crux of the issue is that once clang
promotes something to i64 there is no hope for optimizing it back out.
It's impossible to tell that the indexer is bounded to 32-bit limits,
so the 64 bit additions just have to stay. Ie information is destroyed
when clang promotes for us.

I'd also like to point out that the patch works really well,
especially combined with my previous one. I am able to compile all
clang and clover opencl tests for r600/si now. where as before ~90% of
them crashed. Not that my 9 lines of code are responsible for all that
much. Just a little polish on the edges.