similar to: Wide load/store optimization question

Mark, did you get anywhere with this? We have a similar issue, where a family of otherwise-identical instructions operates on different register classes depending on a non-static property -- functional unit selection in our case. I started to head down the path of using multidefs but quickly abandoned that. I had envisioned a MachineOperand that would hold the functional unit assignment, and

Hi, Same here, my backend only has 64bit load/store. But i still use 64bit virt regs and expand/declare missing instructions by myself.  I'll try looking into sparc backend, thanks. Also, only after writing this post I found a bunch of built-in transforms. Still trying to understand how to use those. By the way, constraint-wise (alignment), is there any difference between virt regclass and

> On Jun 16, 2017, at 2:43 PM, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2017-06-17 4:36 GMT+08:00 upcfrost <upcfrost at gmail.com <mailto:upcfrost at gmail.com>>: > Hi, > > Same here, my backend only has 64bit load/store. But i still use 64bit virt regs and expand/declare missing instructions by myself. > > I'll try

Hi, I've looked through both AMDGPU and Sparc backends, and it seems they also do not perform the thing I want to make. The only backend which is doing it is AArch64, but it doesn't have reg constraints. So, just with an example. I have the following C code: void test() { int a = 1; int b = 2; int c = 3; int d = 4; a++; b++; c++; d++; } Without any frontend optimization is compiles

Well, that is now a slightly different question. Once the compiler can do 64-bit loads/stores for a 64-bit integer type (e.g. C long long), then an optimization pass should be merging the loads/stores before register allocation, so that appropriate registers can be chosen. On Wed, Jun 28, 2017 at 5:43 AM, Peter Bel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > >

> On Apr 2, 2015, at 2:07 PM, Tom Stellard <tom at stellard.net> wrote: > > On Thu, Apr 02, 2015 at 01:35:55PM -0700, Pete Cooper wrote: >> Hi James, Jim >> >> If you *really* want this to work in selection DAG then there is a solution, but its not pretty. >> >> First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you

Hi everyone, I tried to declare multiple data type [i64, i32, v2i32] for a 64 bit register class GPR. It works OK but I have one problem that is hard to find. When I tried to map a load instruction of a v2i32 type (LOAD v2i32:$dst) to load GPR, it always generate two LOAD i32 instead of one LOAD v2i32. Any folds understand how this works? Xiaochu -------------- next part -------------- An HTML

Hello everyone, I think I have found an gvn / alias analysis related bug, but before opening an issue on the tracker I wanted to see if I am missing something. I have the following testcase: define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* %out) { > entry: > ; Just some temporary storage > %tmp.0 = alloca i32 > %tmp.1 = alloca i32 > %tmp.i =

Hi, I'm working on a custom top-down post RA scheduler which builds bundles at the same time for our VLIW processor. I've borrowed most of the implementation from the resource priority queue implemented for the existent VLIW scheduler but applied to the context of MI scheduling. Basically, instructions that are likely to be bundled must be scheduled first (i.e. get higher priority).

this is definitely a bug in AA. 225 for (auto I = CS2.arg_begin(), E = CS2.arg_end(); I != E; ++I) { 226 const Value *Arg = *I; 227 if (!Arg->getType()->isPointerTy()) -> 228 continue; 229 unsigned CS2ArgIdx = std::distance(CS2.arg_begin(), I); 230 auto CS2ArgLoc = MemoryLocation::getForArgument(CS2, CS2ArgIdx, TLI);

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

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.

+ a few others. After following this rabbit hole a bit, there are a lot of mutually recursive calls, etc, that may or may not do the right thing with vectors of pointers. I can fix *this* particular bug with the attached patch. However, it's mostly papering over stuff. Nothing seems to know what to do with a memorylocation that is a vector of pointers. They all expect memorylocation to be a

Okay, so then it sounds like, for now, the right fix is to stop marking masked.gather and masked.scatter with intrarg* options. On Mon, Aug 29, 2016, 1:26 PM Philip Reames <listmail at philipreames.com> wrote: > We might have specification bug here, but we appear to implement what we > specified. argmemonly is specified as only considering pointer typed > arguments. It's

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Philip Reames" <listmail at philipreames.com>, "Davide Italiano" > <davide at freebsd.org>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "Chris Sakalis" <chrissakalis at gmail.com>, "David Majnemer" >

Thank you for the quick fix, I can no longer reproduce the issue. As far a releases go, I am guessing that this is going to be in 4.0? Best, Chris On Tue, Aug 30, 2016 at 9:26 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > Yeah, i just hope it doesn't regress scatter/gather vector code badly. > But at least it's correct now? > > > On Tue, Aug 30, 2016 at 1:11

Great, thank you! On Wed, Aug 31, 2016 at 2:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Chris Sakalis" <chrissakalis at gmail.com> > *To: *"Daniel Berlin" <dberlin at dberlin.org> > *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "David Majnemer" < > david.majnemer

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: >> Tom, >> >> I do not have your call stack, but packetizer calls >> ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is >> the first time you use the new MI sched infrastructure (like your