search for: emenez

Since Jakob had expressed some concerns regarding machine-generated files, I asked him by email about his views on this RFC. Here are the emails that we exchanged in attach. Anyone feel free to jump in via the mailing-list. TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum -------------- next part -------------- An embedded message was scrubbed... From: Jakob Stoklund Olesen <stoklund at 2pi.dk> Subject: Re: [LLVMdev] [RFC] Hexagon insn table refactoring Date: Mon, 13 Aug...

...nstrItinClass; 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 to, "FOO" or any other. TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

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 prologu...

...: one which defined mayStore and one that didn't. The former was to be used when an insn had no pattern and the latter, when mayStore was implied in the pattern. If only TableGen wouldn't warn about non-conflicting attributes at least... -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum

...n 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 to, > "FOO" or any other. > > TIA > > -- > Evandro Menezes Austin, TX emenezes at codeaurora.org > Qualcomm Innovation Center, Inc is a member of Code Aurora Forum > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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 amd.com> wrote: >> Possible to add a test case? > > I am not really sure what I...

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 tha...

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

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 I...

...nment)? > 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 find more information about how this is handled? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum

...mative. 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 codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 03/02/12 10:17, Cameron McInally wrote: > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to >...

...eak 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 Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 03/01/12 15:18, Cameron McInally wrote: > Hi Elena, > > You're correct. LLVM does not align the stack to 32-bytes for AVX and > unaligned moves should be used for YMM spills. > > I wr...

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. > > > > So, if one d...

> > At least for 32bit x86 reserving another register as alternative frame > pointer is very heavy. The above would allow normal spill logic to > decide when to keep a reference in register and when not. It also reuses > existing functionality as much as possible. > Hi Joerg, Yes, this was a problem in my implementation also. Empirically, for the chips I work on, reserving the

Hi Elena, You're correct. LLVM does not align the stack to 32-bytes for AVX and unaligned moves should be used for YMM spills. I wrote some code to align the stack to 32-bytes when AVX spills are present; it does break the x86-64 ABI though. If upstream would be interested in this code, I can arrange with my employer to send a patch to the mailing list. -Cameron On Mar 1, 2012, at 4:09 PM,

..., 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(), but I ended up with the instructions being destroyed. TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Hi, I'm wondering how the Hexagon backend maps instructions to functional units after instructions have been grouped into packets. The order of instructions inside a packet appears to be random and the functional unit information has been lost. How does the code emitter know which functional unit an instruction is supposed to be dispatched to? Thanks, Tom

...ently; 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 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...

...ing will mean that the way in which insns are defined will be changed and a new file, added. Would this be a sensible way to mix a machine-generated file that wouldn't be modified often and one that is meant to be hand modified at will? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum

...iscarded. Perhaps, at this moment, it would suffice to provide an option to specify which sections must be kept. Additionally, perhaps the ELF reader or writer could always keep the .init{.*,_array}, .fini{.*,_array} and preinit_array sections. -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum On 10/01/12 21:06, Sid Manning wrote: > > I committed a patch to update the ReaderELF.cpp that, in light of some > recent changes in the writer, may need another update. WriterELF is > looking fo...