From: Hans de Goede <hdegoede@redhat.com>
To: Tom Stellard <tom@stellard.net>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"mesa-dev@lists.freedesktop.org" <mesa-dev@lists.freedesktop.org>
Subject: Re: llvm TGSI backend (WIP) questions
Date: Wed, 18 Nov 2015 15:53:37 +0100 [thread overview]
Message-ID: <564C90F1.5000700@redhat.com> (raw)
In-Reply-To: <20151113185111.GB29110@yyz>
Hi,
On 13-11-15 19:51, Tom Stellard wrote:
> On Fri, Nov 13, 2015 at 02:46:52PM +0100, Hans de Goede wrote:
>> Hi All,
>>
>> So as discussed I've started working on a TGSI backend for
>> llvm to use as a way to get compute going on nouveau (and other gpu-s).
>>
>> I'm still learning all the ins and outs of llvm so I do not have
>> much to show yet.
>>
>> I've rebased Francisco's (curro's) latest version on top of llvm
>> trunk, and added a commit on top to actual get it build with the
>> latest trunk. So currently I'm at the point where I've just
>> taken Francisco's code, and made it compile, no more and no less.
>>
>> I have a git repo with this work available here:
>>
>> http://cgit.freedesktop.org/~jwrdegoede/llvm/
>>
>> So the next step would be to test this and see if it actually
>> does anything, questions:
>>
>> 1) Does anyone have a simple test case / command where I can
>> invoke just llvm and get TGSI asm output to check ?
>>
>
> The easiest way to do this is with the llc tool which ships with llvm.
> It compiles LLVM IR to target code, which in this case is tgsi.
> I would recommend taking one of the simple examples from
> test/CodeGen/AMDGPU (you may need to get these from llvm trunk, not sure
> what llvm version you are using).
>
> To use llc:
>
> llc -march=tgsi input.ll -o -
>
>
> This will output TGSI.
So after some bugfixing to fix a bunch of segfaults I get:
$ bin/llc -march=tgsi ../test/CodeGen/AMDGPU/add.ll -o -
# BB#0:
UADDs TEMP0x, TEMP0x, 0
LOADgis TEMP1z, [TEMP1y]
UADDs TEMP1y, TEMP1y, 4
LOADgis TEMP1y, [TEMP1y]
UADDs TEMP1y, TEMP1z, TEMP1y
STOREgis [TEMP1x], TEMP1y
UADDs TEMP0x, TEMP0x, 0
RET
ENDSUB
and add.ll has:
;FUNC-LABEL: {{^}}test1:
;EG: ADD_INT {{[* ]*}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;SI: v_add_i32_e32 [[REG:v[0-9]+]], vcc, {{v[0-9]+, v[0-9]+}}
;SI-NOT: [[REG]]
;SI: buffer_store_dword [[REG]],
define void @test1(i32 addrspace(1)* %out, i32 addrspace(1)* %in) {
%b_ptr = getelementptr i32, i32 addrspace(1)* %in, i32 1
%a = load i32, i32 addrspace(1)* %in
%b = load i32, i32 addrspace(1)* %b_ptr
%result = add i32 %a, %b
store i32 %result, i32 addrspace(1)* %out
ret void
}
So the generated code for test1 resmbles the input somewhat but is in no way correct,
e.g. I do not understand why it is assuming that both TEMP0x and TEMP1z contain the
address of the array with the 2 input integers. Nor do I understand why it is using
TEMP1z and TEMP1y as sources for the UADD, where it has been doing the LOAD-s to
TEMP0x and and TEMP1y
And then we've function test2 in add.ll
;FUNC-LABEL: {{^}}test2:
;EG: ADD_INT {{[* ]*}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;EG: ADD_INT {{[* ]*}}T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;SI: v_add_i32_e32 v{{[0-9]+, vcc, v[0-9]+, v[0-9]+}}
;SI: v_add_i32_e32 v{{[0-9]+, vcc, v[0-9]+, v[0-9]+}}
define void @test2(<2 x i32> addrspace(1)* %out, <2 x i32> addrspace(1)* %in) {
%b_ptr = getelementptr <2 x i32>, <2 x i32> addrspace(1)* %in, i32 1
%a = load <2 x i32>, <2 x i32> addrspace(1)* %in
%b = load <2 x i32>, <2 x i32> addrspace(1)* %b_ptr
%result = add <2 x i32> %a, %b
store <2 x i32> %result, <2 x i32> addrspace(1)* %out
ret void
}
Which completely makes the tgsi backend unhappy:
LLVM ERROR: Cannot select: t43: i32,ch = load<LD4[FixedStack0](align=16)> t45:1, FrameIndex:i32<0>, undef:i32
t41: i32 = FrameIndex<0>
t8: i32 = undef
In function: test2
Any hints on where to start looking with fixing these issues would be much
appreciated.
Regards,
Hans
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
next prev parent reply other threads:[~2015-11-18 14:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-13 13:46 llvm TGSI backend (WIP) questions Hans de Goede
[not found] ` <5645E9CC.1040401-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-11-13 14:25 ` Emil Velikov
[not found] ` <CACvgo51PRgQ+=-_p-FWrqa55YmL1Qu8g92fWeWS4e16csaJ8Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-13 14:38 ` Ilia Mirkin
2015-11-13 15:38 ` [Nouveau] " Connor Abbott
2015-11-13 20:42 ` Emil Velikov
[not found] ` <CACvgo52T-D5_TOsROzohrL-YioTCdzGW8zYCH287o3yqr+4tvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-13 20:46 ` Ilia Mirkin
2015-11-13 18:04 ` Samuel Pitoiset
2015-11-13 18:51 ` Tom Stellard
2015-11-16 14:33 ` Hans de Goede
2015-11-18 14:53 ` Hans de Goede [this message]
[not found] ` <564C90F1.5000700-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-11-18 15:11 ` [Mesa-dev] " Tom Stellard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564C90F1.5000700@redhat.com \
--to=hdegoede@redhat.com \
--cc=mesa-dev@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
--cc=tom@stellard.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.