search for: adddef

...e building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. Once you move beyond the fixed operands, it can't be determined automatically if the added register should be a use or a def. But I think it would be convenient to add addUse() and addDef() methods to MachineInstrBuilder, instead of requiring the tedious addReg(..., RegState::Define). /jakob

I've attached a script I wrote that pulls all the setGeneric definitions out of a set of R files and puts them in a separate file, default allGenerics.R. I thought it might help others who find themselves in a similar situation. The "situation" was that I had to change the order in which files in my package were parsed; the scheme in which the generic definition is in the

I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. -Jim On Feb 19, 2013, at 7:14 PM, reed kotler <rkotler at mips.com> wrote: > Hi Jim, > > One thing that seems strange to me is that if do a BuildMI, if you put a register inside the first parens, then it

...ast perhaps the machine verifier should check that they match what's actually on the operands (does it currently?). Right now it's pretty easy to construct an MI that's inconsistent with its MCInstrDesc information. -Jim > > But I think it would be convenient to add addUse() and addDef() methods to MachineInstrBuilder, instead of requiring the tedious addReg(..., RegState::Define). > > /jakob >

Hi Jim, One thing that seems strange to me is that if do a BuildMI, if you put a register inside the first parens, then it will treat it as a def, but if you just .addReg it won't (by default), even though it should know from the instruction definition. Seems like it should do that. Why would you want it to not do that? Reed On 02/18/2013 01:22 PM, Jim Grosbach wrote: > Hi Reed,

This shouldn't have parsed. movq (%gs), %r14 That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week. That's probably why it printed as %ebp. I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates