search for: multiop

Evan, Timo, Carlos (and everyone else), I have somewhat similar interest. What would you say to a some sort of a "global cycle" field/marker to determine all instructions scheduled at a certain "global" cycle. That way the "bundle"/packet/multiop can be identified at any time via a common "global cycle" value. I could see that being set first in pre-ra scheduler and refined later (just as Timo is describing). No changes required to any existing passes, unless a pass "needs" to know about "bundle"/packet. New in...

Hi Sergei, > What would you say to a some sort of a "global cycle" field/marker to > determine all instructions scheduled at a certain "global" cycle. That way > the "bundle"/packet/multiop can be identified at any time via a common > "global cycle" value. But RA would need to know about this global cycle field, right? Cause a register can be reused in the same "global cycle" as it is killed. Carlos > -----Original Message----- > From: llvmdev-bounces a...

...39;Stripf, Timo'; 'LLVM Dev' Subject: RE: [LLVMdev] VLIW Ports Hi Sergei, > What would you say to a some sort of a "global cycle" field/marker to > determine all instructions scheduled at a certain "global" cycle. That way > the "bundle"/packet/multiop can be identified at any time via a common > "global cycle" value. But RA would need to know about this global cycle field, right? Cause a register can be reused in the same "global cycle" as it is killed. Carlos > -----Original Message----- > From: llvmdev-bounces a...

...Dev' > Subject: RE: [LLVMdev] VLIW Ports > > Hi Sergei, > >> What would you say to a some sort of a "global cycle" field/marker to >> determine all instructions scheduled at a certain "global" cycle. That way >> the "bundle"/packet/multiop can be identified at any time via a common >> "global cycle" value. > > But RA would need to know about this global cycle field, right? Cause a > register can be reused in the same "global cycle" as it is killed. > > Carlos > >> -----Original Messag...

...ackwards to extract info readily available in MIs). 3) Your group is working on a "new" scheduler, and the best I understand it would be same general algorithm moved "closer" to RA. I also understand that at first it would not have added support for "packets"/bundles/multiops in VLIW definition (or will it?). If they will be presented, interesting discussion on how subsequent passes will be modified to recognize them would follow... but we had another thread on this topic not that long ago. So, IMHO the following would make sense: 1) It would be very nice if we...

Sergei, I would say that each target has its own scheduling strategy that has changed considerably over time. We try to maximize code reuse across targets, but it's not easy and done ad hoc. The result is confusing code that makes it difficult to understand the strategy for any particular target. The right thing to do is: 1) Make it as easy as possible to understand how scheduling works for

Hi Evan (and all), > I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. The approach in the patch I sent (and I believe Timo's code works similar, according to his explanations) is precisely to make "bundles" no different

Hi Timo, I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. Furthermore, if this is something that no current targets are using, then it cannot be adopted into LLVM mainline. I think what we need is a concept of a sequence of fixed machine

...terface structure */ + struct xfs_attrlist_cursor pos; /* opaque cookie, list offset */ + uint32_t flags; /* which namespace to use */ + uint32_t buflen; /* length of buffer supplied */ + void __user *buffer; /* returned names */ +} xfs_fsop_attrlist_handlereq_t; + +typedef struct xfs_attr_multiop { + uint32_t am_opcode; +#define ATTR_OP_GET 1 /* return the indicated attr's value */ +#define ATTR_OP_SET 2 /* set/create the indicated attr/value pair */ +#define ATTR_OP_REMOVE 3 /* remove the indicated attr */ + int32_t am_error; + void __user *am_attrname; + void __user *am_attrvalue;...