similar to: extract_vector_elt type mismatch?

Displaying 20 results from an estimated 300 matches similar to: "extract_vector_elt type mismatch?"

2016 Aug 18
2
extract_vector_elt type mismatch?
On 18 August 2016 at 10:46, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think this is just intended as a quirk for some weird targets that have a > legal vector type, but the scalar type itself is not legal, so it requires > an implicit extension when extracting it. I think it's a pretty common RISC situation. I notice you deprecated the mismatching
2019 Nov 28
2
Question on pattern matching extractelt
Hi, I have an issue with pattern matching. I have the following SelectionDAG: t13: i32 = extract_vector_elt t2, Constant:i64<1> That I am trying to match with the following pattern: def : Pat<(extractelt (v4i16 SingleReg:$v), 1), (SRADd1 SingleReg :$v, (i64 16))>; But for some reason the pattern does not match. It seems to be due to the fact extract_vector_elt's result
2011 Dec 10
1
[LLVMdev] Types inference in tblgen: Multiple exceptions
On 10/12/2011 01:32, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Eli, >> Thanks for your response. Please see my responses below. >> >> >> On 10/12/2011 00:28, Eli Friedman wrote: >>> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>> wrote:
2020 Jan 10
2
[RFC][SDAG] Convert build_vector of ops on extractelts into ops on input vectors
I have added a few PPC-specific DAG combines in the past that follow this pattern on specific operations. Now that it appears that this would be useful to do on yet another operation, I'm wondering what people think about doing this in the target-independent DAG Combiner for any legal/custom operation on the target. TL; DR; The generic pattern would look like this: (build_vector (op
2011 Dec 10
5
[LLVMdev] Types inference in tblgen: Multiple exceptions
Hi Eli, Thanks for your response. Please see my responses below. On 10/12/2011 00:28, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >> Hi all, >> >> I am writing a back-end for a processor that has complex type registers. >> It has two functional units to perform complex multiplications. >> From clang,
2011 Dec 09
2
[LLVMdev] Types inference in tblgen: Multiple exceptions
Hi all, I am writing a back-end for a processor that has complex type registers. It has two functional units to perform complex multiplications. From clang, I emulate a complex multiplication using vectors and, at the IR, I got this tblgen-friendly pattern (real component) : (set RARegs:$dst, (insertelt RARegs:$src, (i16 (trunc (add (ncmul (sext (i16
2020 Jan 11
2
[RFC][SDAG] Convert build_vector of ops on extractelts into ops on input vectors
Thanks so much for your feedback Simon. I am not sure that what I am proposing here is at odds with what you're referring to (here and in the PR you linked). The key difference AFAICT is that the pattern I am referring to is probably more aptly described as "reducing scalarization" than as "vectorization". The reason I say that is that the inputs are vectors and the output
2016 Aug 12
4
Invoke loop vectorizer
I'm not compiling it to x86. Should loop optimizer something independent of the target? If so, should the vectorized code on IR level? On Aug 12, 2016 11:39 AM, "Daniel Berlin" <dberlin at dberlin.org> wrote: > cat > test.c > > #define SIZE 128 > > void bar(int *restrict A, int* restrict B,int K) { > > #pragma clang loop vectorize(enable)
2020 Jan 11
2
[RFC][SDAG] Convert build_vector of ops on extractelts into ops on input vectors
Absolutely. We do it for scalars, so it would likely be a matter of just extending it. But that is one example. The issue of extracting elements, performing an operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig
2015 Jul 04
3
[LLVMdev] Declare multiple data type for a register class in tblegen
Oh, they have selection details in the end. Let me check that first... On Sat, Jul 4, 2015 at 4:05 PM Xiaochu Liu <xiaochu1122 at gmail.com> wrote: > Hi Matt, > > I tried debug-only=isel and have some more informations. > The steps before 'Legalized selection'( excluding it) all use v2i32 load. > At the step of 'Legalized selection', it replaced one v2i32
2014 Aug 11
2
[LLVMdev] tablegen pattern
Hi Guys, I have a taget instruction which take a vec4 and returns a vec4.( say instruction “vec4:$dst mod( vec4:$src)" ) And I want to use it to match i an ir instruction/intrinsic function( say " float:$dst llvm.irmod( vec4:$src)" which takes a vec4, output a float. I think the procedure is: when I see the intrinsic llvm.irmod, I need to call "extractlt(
2016 Aug 12
2
Invoke loop vectorizer
Hi Andrey, Thanks. I found even when loop vectorizer and SLP vectorizer are enabled, my simple test still not get optimized. I also tried clang pragma in my test to force vectorization. What do you think is the problem? Test: #define SIZE 8 void bar(int *A, int* B,int K) { #pragma clang loop vectorize(enable) vectorize_width(2) unroll_count(8) for (int i = 0; i < SIZE; ++i) A[i]
2016 Aug 12
2
Invoke loop vectorizer
Hi Daniel, I increased the size of your test to be 128 but -stats still shows no loop optimized... Xiaochu On Aug 12, 2016 11:11 AM, "Daniel Berlin" <dberlin at dberlin.org> wrote: > It's not possible to know that A and B don't alias in this example. It's > almost certainly not profitable to add a runtime check given the size of > the loop. > > >
2011 Dec 09
0
[LLVMdev] Types inference in tblgen: Multiple exceptions
On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan <ivanllopard at gmail.com> wrote: > Hi all, > > I am writing a back-end for a processor that has complex type registers. > It has two functional units to perform complex multiplications. >  From clang, I emulate a complex multiplication using vectors and, at > the IR, I got this tblgen-friendly pattern (real component) : >
2016 Mar 30
3
infer correct types from the pattern
i'm getting a Could not infer all types in pattern! error in my backend. it is happening on the following instruction: VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). how do i make it use appropriate types? in other words if it is f32 then use v4v32 and if it is i32 then use v4f32. i'm not sure even where to start? any help is appreciated.
2015 Aug 27
2
preserve registers across function call
Hi Marcello, Thanks for your reply. I will try to pass down the mask! I have one more question. In my backend I return CSR_RegMask in getCallPreservedMask and return CSR_SaveList in getCalleeSavedRegs. Is that a correct setup? I dumped the regmask and found that callee saved regs are marked 1 and non-callee saved regs are 0. Thanks, Xiaochu On Wed, Aug 26, 2015 at 5:58 PM Marcello Maggioni
2016 Aug 11
2
Invoke loop vectorizer
Hi there , I use clang-cl /Qvec test.c to compile the code. But the pass LoopVectorizer is never invoked. I was wondering if this is sufficient to enable auto vectorizer? Thanks, Xiaochu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160811/8b6cb760/attachment.html>
2011 Dec 10
0
[LLVMdev] Types inference in tblgen: Multiple exceptions
On Dec 9, 2011, at 4:12 PM, Ivan Llopard wrote: > Hi Eli, > Thanks for your response. Please see my responses below. > > On 10/12/2011 00:28, Eli Friedman wrote: >> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >>> Hi all, >>> >>> I am writing a back-end for a processor that has complex type registers.
2011 Dec 10
0
[LLVMdev] Types inference in tblgen: Multiple exceptions
On Fri, Dec 9, 2011 at 4:12 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Eli, > Thanks for your response. Please see my responses below. > > > On 10/12/2011 00:28, Eli Friedman wrote: >> >> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> >>  wrote: >>> >>> Hi all, >>> >>> I am writing
2015 Jul 03
2
[LLVMdev] Declare multiple data type for a register class in tblegen
Thanks. I'm gonna try tomorrow and let you know. On Thu, Jul 2, 2015 at 6:51 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 07/02/2015 06:41 PM, Xiaochu Liu wrote: > > Hi Matt, > > > > I did call addRegisterClass in TargetLowering for all the possible > > types in the register. And for typecasting instructions (i32 to i64), > > it works.