Yeah, agree adding SDNodes for every intrinsic sounds odd.
SDNodes should be the source of the selection process, not it's destination.
Christian.
Am 17.06.2014 03:51, schrieb Marek Olšák:
Is there any specific reason for using SDNodes for everything?
Using intrinsics directly in patterns
On Mon, Jun 16, 2014 at 09:19:59PM +0200, Marek Olšák wrote:
Why are there SDNodes for the other sample intrinsics then?
The reason there are SDnodes for sample intrinsics is because at one point he
had
to modify the type of the resource description and the easiest way to do that
was by
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
All fields of the MIMG opcodes are exposed and can be set by Mesa,
even DMASK. All GATHER4 variants are added and there are a lot of
Why are there SDNodes for the other sample intrinsics then?
Marek
On Mon, Jun 16, 2014 at 5:45 PM, Tom Stellard t...@stellard.net wrote:
On Thu, Jun 12, 2014 at 02:11:10AM +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
On 06/16/2014 08:45 AM, Tom Stellard wrote:
You don't need to add new SDNodes for all these instructions, you can just use
the intrinsic directly in the pattern.
The only reason to add SDNodes, is if there are optimizations / special lowering
we can do for these instructions.
I kind of like
Is there any specific reason for using SDNodes for everything?
Using intrinsics directly in patterns seems to result in a smaller
amount of code, which is always good.
Marek
On Mon, Jun 16, 2014 at 8:12 PM, Matt Arsenault
matthew.arsena...@amd.com wrote:
On 06/16/2014 08:45 AM, Tom Stellard
From: Marek Olšák marek.ol...@amd.com
This adds a new type of intrinsic and SDNode: SampleRaw.
All fields of the MIMG opcodes are exposed and can be set by Mesa,
even DMASK. All GATHER4 variants are added and there are a lot of them.
v2: document DMASK behavior
---
