Displaying 3 results from an estimated 3 matches for "d53613".
2018 Dec 19
3
[RFC] Matrix support (take 2)
Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> writes:
> I spent some time chatting with Adam about this and have a better
> understanding of his concerns here. It seems to me that if having
> masking intrinsics is the long-term solution we want, we should do
> that now (for add and sub) rather than building arbitrary matrix
> layout info into
2018 Dec 20
3
[RFC] Matrix support (take 2)
...honestly don't know the answers to these questions. But I think they
>> are important to consider, especially if intrinsics are seen as a bridge
>> to first-class IR support for masking.
>
> I think its sensible to use masking intrinsics (or EVL
> https://reviews.llvm.org/D53613) on IR level and masked SD nodes in
> the backend. However, i agree that intrinsics should just be a bridge
> to native support mid term.
The biggest question I have is how such a transition would happen.
Let's say we have a full set of masking intrinsics. Now we want to take
one IR-lev...
2018 Dec 19
3
[RFC] Matrix support (take 2)
> On Dec 19, 2018, at 11:09 AM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>> On Dec 18, 2018, at 10:18 PM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote:
>>
>>> I don’t understand this. What is the benefit of providing layout info to element wise operations? This defeats the goal of having simple lowering