search for: gencodeemitter

...ely there are naming discrepancies between the >> instruction format fields and the operand names in all existing >> code emitters that use TableGen, which would require some >> significant renaming cleanup. > > Not sure what you mean. Example? I'm saying that the GenCodeEmitter tablegen back end should look up MI operand number by name, rather than assuming the order of declarations matches the order of the operands. This way tablegen can emit an error if the field name and operand name fail to match rather than silently producing an incorrect GenCodeEmitter. cla...

On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > I noticed that the TableGen code emitter generator assumes that the > instruction fields are declared in the instruction format in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to determine which operand of the MI to use . See

...Inst{7-4} = sy; Inst{3-0} = 0; They even mostly kept the instruction formats! Can I tell tablegen to have two encodings and switch between them using a predicate? I do not want to create new instructions (e.g. ADD_KCPSM3 and ADD_KCPSM6). If that is not possible I will just dump the tablegen's *GenCodeEmitter.inc file with the getBinaryCodeForInstr() and write it by hand. I guess this is the only place where opcodes are used? (I do not use LLVM's MC disassembler.) Cheers, Jara -- Space--the final frontier! http://linkedin.com/in/jaroslavsykora

>> Can I tell tablegen to have two encodings and switch between them >> using a predicate? After some deliberations, I modified tablegen to generate several versions of the GenCodeEmitter file. My tablegen now accepts a new command line parameter called "emitter-instfld". This specifies the name of the field in Instruction that holds the encoded bytes. In my target's td files I simply specify both encodings at the same time. This is my target's Instruction base cl...

...eEmitter::finishFunction [This runOnMachineFunction could definitely be generalized, i.e. implemented in a base class ('EmitterMachineFunctionPass' or a better name). This base class would then have (abstract) emitInstruction, emitOperand, etc... methods. It should also integrate with the *GenCodeEmitter emitted by tblgen so that you get automatic code emission. When implementing a new target, one would simply need to inherit the baseclass, and override the functions necessary to tweak output.]

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

...ObjDir)/%GenAsmWriter1.inc.tmp : %.td $(ObjDir)/.dir $(Echo) "Building $(<F) assembly writer #1 with tblgen" - $(Verb) $(TableGen) -gen-asm-writer -asmwriternum=1 -o $@ $< + $(Verb) $(TableGen) -gen-asm-writer -asmwriternum=1 -o $(call SYSPATH, $@) $< $(TARGET:%=$(ObjDir)/%GenCodeEmitter.inc.tmp): \ $(ObjDir)/%GenCodeEmitter.inc.tmp: %.td $(ObjDir)/.dir $(Echo) "Building $(<F) code emitter with tblgen" - $(Verb) $(TableGen) -gen-emitter -o $@ $< + $(Verb) $(TableGen) -gen-emitter -o $(call SYSPATH, $@) $< $(TARGET:%=$(ObjDir)/%GenDAGISel.inc.tmp): \ $(O...

...> [This runOnMachineFunction could definitely be generalized, i.e. > implemented in a base class ('EmitterMachineFunctionPass' or a better > name). This base class would then have (abstract) emitInstruction, > emitOperand, etc... methods. It should also integrate with the > *GenCodeEmitter emitted by tblgen so that you get automatic code > emission. When implementing a new target, one would simply need to > inherit the baseclass, and override the functions necessary to tweak > output.] runOnMachineFunction is a standard LLVM message we cannot play around with it. Please r...

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron