similar to: [LLVMdev] Changing order of instructions

Hi Jakob, > New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 > are 32 bit virt. regs. > New_MI_2:: Vreg2 = COPY C:lo_sub_reg. > New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B > is a > 64 bit virt reg. I used this approach and it worked find until I hit, what I believe is, a bug in the register coalescer. When the register

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

Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation

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

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

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 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 Jul 5, 2012, at 6:01 PM, "Pranav Bhandarkar" <pranavb at codeaurora.org> wrote: > Hi Jakob, > >> New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2 >> are 32 bit virt. regs. >> New_MI_2:: Vreg2 = COPY C:lo_sub_reg. >> New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B >> is a >> 64 bit

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

Saludo cordial para cada uno. Les pido ayuda para generar números aleatorios de una mixtura k-puntos. Sabemos que la función de distribución F es una mixtura k-puntos si es de la forma F(x) = p_1 F_1(x) + p_2 F_2(x) + … + p_k F_k(x), donde F_j es una función de distribución de probabilidad, p_j > 0 y suma(p_j) = 1, para j = 1, 2, …, k. En mi caso particular F es la suavización de la

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.

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

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

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