similar to: [LLVMdev] [RFC] Hexagon insn table refactoring

We are working on enabling the MC code-emitter for Hexagon and it's necessary to add the missing opcode bits to the insn tables. I'm considering scooping the opcode bits from the processor source files for correctness' and expediency's sake and I'm afraid that a significant refactoring of the current insn tables will be necessary. I intend to create classes for each insn

On Aug 22, 2012, at 9:40 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > On 08/21/12 16:49, Jim Grosbach wrote: >> >> I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. >> >> Beyond that, I don't see an alternative to an audit

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

Hello, I believe MCInstrDesc::getSchedClass() is what you're looking for. -Jim On Nov 28, 2011, at 5:03 PM, Evandro Menezes wrote: > I'd appreciate some help in figuring out how to determine which > InstrItinClass an instruction belongs to. > > For example, an InstrItinClass is defined in Schedule.td as: > > def FOO : InstrItinClass; > > Which is then used

I'd appreciate some help in figuring out how to determine which InstrItinClass an instruction belongs to. For example, an InstrItinClass is defined in Schedule.td as: def FOO : InstrItinClass; Which is then used to build an InstrItinData in ProcessorItineraries and to specify the class of a particular instruction. I'd like to find out from a given instruction which class it belongs

Sebastian, If not a test, how about a patch in the documentation for TableGen about this new feature that you're making available? -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 06/20/12 16:02, Sebastian Pop wrote: > On Wed, Jun 20, 2012 at 3:40 PM, Villmow, Micah<Micah.Villmow at

On Thu, Jun 21, 2012 at 10:31 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: > Sebastian, > > If not a test, how about a patch in the documentation for TableGen about > this new feature that you're making available? That's a good point. I will prepare a patch for the docs. Thanks for your review! Sebastian -- Qualcomm Innovation Center, Inc is a member of

Owen, On 11/29/12 18:16, Owen Anderson wrote: >> Will the size of the >> packet be properly accounted for by the MCObjectStreamer if we have to pad >> the packet (mainly for fetch alignment)? > The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. Where could I

On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: ... > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > confirms that the use of a frame-pointer is optional. > > So, if one doesn't use ENTER in the prologue and uses RSP to access local >

Cameron, Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not normative. See foot note 7 in the same page. Figure 3.4 on page 21 confirms that the use of a frame-pointer is optional. So, if one doesn't use ENTER in the prologue and uses RSP to access local variables, RBP may be used as a calee-saved GPR. -- Evandro Menezes Austin, TX emenezes at

Has anyone attempted the port of LLVM to a VLIW architecture? Is there any publication about it? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Cameron, Aligning the stack to 32 bytes when there are auto AVX vector variables present shouldn't necessarily break the x86-64 ABI, as long as smaller auto variables remain properly aligned. A similar approach was taken for i386 in GCC in order to support SSE vectors. Perhaps you could elaborate where the ABI was violated when your patch is applied. HTH -- Evandro Menezes

On Fri, Mar 02, 2012 at 11:58:29AM -0500, Cameron McInally wrote: > On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> > wrote: > ... > > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > > confirms that the use of a frame-pointer is optional.

Given a segment of a MachineBasicBlock containing the instructions [MI4, MI5, MI6] at an arbitrary point, what would be the best way to change this segment with the same instructions in a different order, say, [MI5, MI6, MI4]? I looked into splice(), but it was impossible to hold iterators that remained valid before and after the splicing. I tried erase/remove() with insert/insertAfter(),

Jakob, One more question. You had suggested 'ValueCols' as of type list<list<string> >. Does the TableGen know how to extract it? It appears to me that we may have to add support for that. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Make sure to pull from the repo because the TableGen docs have been moved from HTML to reStructuredText very, very recently; it would be unfortunate if you did your work on the now-nonexistent HTML version, only to find that that file no longer exists. --Sean Silva On Thu, Jun 21, 2012 at 8:33 AM, Sebastian Pop <spop at codeaurora.org> wrote: > On Thu, Jun 21, 2012 at 10:31 AM, Evandro

Sid, It's a real problem when section GC is active. It's not very common, but, typically, global constructors and destructors are the primary instances that may be incorrectly discarded. The statement KEEP in GNU linker scripts specifies which sections should be kept in the final output even if GC judges that it could be discarded. Perhaps, at this moment, it would suffice to

On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. > > It's possible to override this behavior by setting neverHasSideEffects = 1. > > It was

On Fri, Aug 3, 2012 at 12:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Why wouldn't it be acceptable for the *.td files defining the instructions >> and the relations between them to be generated and not written by hand? > > Because it defeats the purpose of open source. > > It would be impossible to improve the way Hexagon models instructions

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Jakob Stoklund Olesen > Sent: Friday, August 03, 2012 10:02 AM > To: Sebastian Pop > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] TableGen related question for the Hexagon > backend > > > On Aug 2, 2012, at 11:24 PM, Sebastian Pop